Use the Implicit Flow

Kicking off 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 /authorize endpoint. If you are using the default Okta authorization server, then your request URL would look something like this:


Note the parameters that are being passed:

  • client_id matches the Client ID of your Okta OAuth application that you created above. 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, though additional scopes can be requested. For more information about scopes, see here.
  • redirect_uri is the callback location where the user-agent will be directed to along with the access_token. This must match one of the "Login redirect URIs" you specified when you were creating your Okta application in Step 1.
  • state is an arbitrary alphanumeric string that the authorization server will reproduce when redirecting the user-agent back to the client. This is used to help prevent cross-site request forgery.

For more information on these parameters, see the OAuth 2.0 API reference.

If the user does not have an existing session, this will open the Okta Sign-in Page. If they have an existing session, or after they authenticate, they will be redirected back to the specified redirect_uri along with a token as a hash fragment:


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