Use the Implicit flow

Using 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 Custom 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 in the previous step. 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 were creating your Okta application in the previous step.
  • 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.

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:


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