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:
https://${yourOktaDomain}/oauth2/default/v1/authorize?client_id=0oabv6kx4qq6
h1U5l0h7&response_type=token&scope=openid&redirect_uri=http%3A%2F%2Flocalhost%3
A8080&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 previous step. You can find it at the bottom of your application's General tab.response_type
istoken
. It could also beid_token
or both.scope
isopenid
, 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 theaccess_token
. This must match one of the Login 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:
http://localhost:8080/#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.