Implement authorization by grant type

This guide explains how to implement an OAuth 2.0 Implicit flow for your app with Okta.

---

Learning outcomes

• Understand the OAuth 2.0 Implicit flow.
• Set up your app with the Implicit grant type.
• Implement the Implicit flow in Okta.

What you need

• Okta Developer Edition organization (opens new window)
• An app that you want to implement OAuth 2.0 authorization with Okta

Note: Okta's Developer Edition makes most key developer features available by default for testing purposes. Okta's API Access Management product — a requirement to use Custom Authorization Servers — is an optional add-on in production environments.

---

About the Implicit grant

The Implicit flow is not a recommended approach, as it is extremely challenging to implement the Implicit flow securely. Okta recommends that you use the Authorization Code flow with PKCE instead. To select the appropriate flow to use for your application, see OAuth 2.0 and OpenID Connect overview's decision flowchart.

If you are building a Single-Page Application (SPA) on browsers that don't support Web Crypto for PKCE, then the Implicit flow can be used for controlling access between your SPA and a resource server. The Implicit flow is intended for applications where the confidentiality of the client secret can't be guaranteed. In this flow, the client doesn't make a request to the /token endpoint, but instead receives the access token directly from the /authorize endpoint. The client must be capable of interacting with the resource owner's user agent and capable of receiving incoming requests (through redirection) from the authorization server.

Grant-type flow

Implicit flow

The Implicit flow contains the following interaction steps:

1. The Client sends a request to the authorization server (Okta) for an access token.

   You need to register your app so that Okta can accept the authorization request. See Set up your app to register and configure your app with Okta. After registration, your app can initiate this authorization request to Okta for an access token. See Request for tokens to implement this request.

2. The authorization server redirects the User browser to an authentication prompt (the Okta Sign-In Page), where the user authenticates.

3. User authenticates with the authorization server (Okta) and provides consent.

   For Okta to authenticate the user credentials, Okta needs user profile data. See Add a user using the Admin Console (opens new window), Import Users, and the Users API. Alternatively, you can set up self-service registration to allow users to register their membership with the app.

4. Okta redirects the browser back to the specified redirect URI, along with access and ID tokens as a hash fragment in the URI.

5. Your application extracts the tokens from the URI. See Extract tokens from redirect URI.

6. The Client can use the access token to call the resource server (for example, an API) on behalf of the User. See Validate access token.

Set up your app

Before you can implement authorization, you need to register your app in Okta by creating an app integration from the Admin Console.

1. In the Admin Console, go to Applications > Applications.
2. Click Create App Integration.
3. Select

   OIDC - OpenID Connect

   as the Sign-in method.

4. Select Single-Page Application as the Application type, then click Next.

   Note: It is important to choose the appropriate application type for apps that are public clients. Failing to do so may result in Okta API endpoints attempting to verify an app's client secret, which public clients are not designed to have and would break the sign-in or sign-out flow.

5. Specify the App integration name.

6. Select Implicit (Hybrid) as a Grant type.

7. Specify the Sign-in redirect URIs where the user is directed to along with the access token.

8. Fill in the remaining details for your app integration, then click Save.

From the General tab of your app integration, save the generated Client ID value to implement your authorization flow.

Use an SDK

Okta recommends using existing libraries and OAuth 2.0 helper methods to implement your authentication flow. You can use one of Okta's SDKs or an open-source library if an appropriate Okta SDK is not available. See Languages & SDKs overview for a list of Okta SDKs that you can download to start using with your app.

Flow specifics

Without using existing libraries, you can make a direct request to Okta's OIDC & OAuth 2.0 API through the /authorize endpoint.

Request for tokens

This flow is very similar to the Authorization Code flow, except that the response_type is token and/or id_token instead of code.

Your application redirects the user's browser to your authorization server's](/docs/concepts/auth-servers/) /authorize endpoint. If you are using the default custom authorization server, then your request URL would look something like this:

https://${yourOktaDomain}/oauth2/default/v1/authorize?client_id=0oabv6kx4qq6h1U5l0h7&response_type=token&scope=openid&redirect_uri=&redirect_uri=https%3A%2F%2Fexample.com&state=state-296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601&nonce=foo'

Note the parameters that are being passed:

• client_id matches the Client ID of your Okta OAuth application that you created in the Set up your app section. You can find it at the bottom of your application's General tab.
• response_type is token. It could also be id_token or both.
• scope is openid, which is required, but additional scopes can be requested. See the Create Scopes section of the Create an authorization server guide.
• redirect_uri is the callback location where the user agent is directed to along with the access_token. This must match one of the Sign-in redirect URIs that you specified when you created your Okta app integration in the Set up your app section.
• state is an arbitrary alphanumeric string that the authorization server reproduces when redirecting the user agent back to the client. This is used to help prevent cross-site request forgery.

See the OAuth 2.0 API reference for more information on these parameters.

Extract tokens from redirect URI

If the user doesn't have an existing session, the request opens the Okta sign-in page. If they have an existing session, or after they authenticate, the user is redirected back to the specified redirect_uri along with a token as a hash fragment:

https://${yourOktaDomain}/#access_token=eyJhb[...]erw&token_type=Bearer&expires_in=3600&scope=openid&state=state-296bc9a0-a2a2-4a57-be1a-d0e2fd9bb601

Your application must now extract the token(s) from the URI and store them.

Validate access token

When your application passes a request with an access token, the resource server needs to validate it. See Validate access tokens.

Next steps

Now that you have implemented authorization in your app, you can add features such as:

• Brand customization (custom domain, custom SMS messages, custom emails, and custom error pages).
• Self-service enrollment.