Before authorization begins, it first generates a random string to use for the state parameter. The client will need to store this to be used in the next step.

/authorize?
  response_type=token
  &client_id=
  &redirect_uri=/implicit.html
  &scope=photo
  &state=

For this demo, we've gone ahead and generated a random state parameter (shown above) and saved it in a cookie.

Click "Authorize" below to be taken to the authorization server. You'll need to enter the username and password that was generated for you.

The user was redirected back to the client, and you'll notice there is now a fragment component in the URL that contains the access token as well as some other information:

#access_token=&token_type=&expires_in=&scope=&state=

You need to first verify that the state parameter matches the value stored in this user's session so that you protect against CSRF attacks.

This does not stop a malicious actor from injecting an access token into your client. There is no solution in OAuth for protecting the Implicit flow, and it is being deprecated in the Security BCP.

Depending on how you've stored the state parameter (in a cookie, session, or some other way), verify that it matches the state that you originally included in step 1. Previously, we had stored the state in a cookie for this demo.

Does the state stored by the client () match the state in the redirect ()?

That's it! Now that you've verified the state parameter, you can start using the access token that was provided in the URL fragment.

For reference, here are the values the client is ready to use.

access_token
token_type
expires_in
scope

Note that this is an OAuth 2.0 Bearer Token, which means it is opaque to the client and the client should not try to parse the token. Some authorization servers may use JWT values, but others may use random strings. This is in contrast to an OpenID Connect ID Token which is intended to be parsed by the client. See the OpenID Connect for an example of parsing an ID token.