Okta

Owned by shreedutta.mukherjee (Deactivated)
Last updated: Apr 08, 2022
3 min read

 

Okta is a cloud service that organizes workforce and customer identities. It helps companies manage and secure user authentication into applications. It helps the developers to build identity controls into applications, website web services, and devices.



Authorization

OAuth 2.0

There are two main types of authentication that you can perform with Okta:

  • The OpenID Connect (OIDC) protocol is built on the OAuth 2.0 protocol and helps authenticate users and convey information about them. It's also more opinionated than plain OAuth 2.0, for example in its scope definitions.

  • The OAuth 2.0 protocol controls authorization to access a protected resource, like your web app, native app, or API service.

The OAuth 2.0 protocol provides API security through scoped access tokens. OAuth 2.0 enables you to delegate authorization, while OIDC enables you to retrieve and store authentication information about your end users. OIDC extends OAuth 2.0 by providing user authentication and single sign-on (SSO) functionality.

For most of your app auth requirements, we recommend that you use the OAuth 2.0 and OIDC protocols through the different solutions Okta provides, as outlined in Redirect authentication vs. embedded authentication. To get started with auth implementation and find sample apps, see Sign users in.

OAuth 2.0 is a standard that apps use to provide client applications with access. If you would like to grant access to your application data in a secure way, then you want to use the OAuth 2.0 protocol.

When you create your Okta app, you must be sure to enter Sapper's OAuth callback URL -Sapper.

The OAuth 2.0 spec has four important roles:

  • Authorization server: The server that issues the access token. In this case Okta is the authorization server.

  • Resource owner: Normally your application's end user that grants permission to access the resource server with an access token.

  • Client: The application that requests the access token from Okta and then passes it to the resource server.

  • Resource server: Accepts the access token and must verify that it's valid. In this case, this is your application.

Other important terms:

  • OAuth 2.0 grant: The authorization given (or granted) to the client by the user. Examples of grants are authorization code and client credentials. Each OAuth grant has a corresponding flow. See Choosing an OAuth 2.0 flow.

  • Access token: The token issued by the authorization server (Okta) in exchange for the grant.

  • Refresh token: An optional token that is exchanged for a new access token if the access token has expired.

The usual OAuth 2.0 grant flow looks like this:

  • Client requests authorization from the resource owner (usually the user).

  • If the user gives authorization, the client passes the authorization grant to the authorization server (in this case Okta).

  • If the grant is valid, the authorization server returns an access token, possibly alongside a refresh and/or ID token.

  • The client now uses that access token to access the resource server.

Okta Connection

Okta OAuth2.0 Connection 

Input 

Key 

Description

Example

Select application

application

Select Okta application

 

Connection type

connection type

Select the type of connection.

REST

REST connection type

rest connection type

Select the type of REST connection.

 OAuth2.0

Connection name

name

Provide a name for the connection.

 Okta connection

Connection description

description

Provide a description for the connection.

 

Host name

host 

Provide a string value for the URL of user's Okta account.

 

Grant type

grant type

Provide the grant type - Authorization code, Password, Client Credentials.

 

Actions

Get Users

Get Users | key: getUsers