Implicit grant flow

In the implicit grant flow, the Authorization Server provides an access token directly to a client app. The flow does not involve an authorization code and refresh token, which differentiates it from the authorization code grant flow. In this way, it is considered a lightweight version of the authorization code grant flow.

In this flow, the protected resources that a client app requests belong to an end user (resource owner). While being simpler than the authorization code grant flow, the implicit grant flow is also less secure. It is only recommended for public client apps, for example, single page applications that use scripting languages such as JavaScript.

Use case

Imagine a bookstore API whose resources are book orders that end users submit through an external Fast Book Orders web app. The app operates on a single page. It needs users’ permissions to post orders on their behalf. The implicit grant flow may apply to this scenario because the single-page app is not well-suited to storing a refresh token securely, but it can store a shorter-lived access token with low risk of the token being compromised.

Response

In the implicit grant flow, the Authorization Server passes an access token to a user agent through a fragment identifier (redirect#access_token).

https://bookstore.api.akamai.com/redirect#access_token=<token>

Process

Here’s a detailed overview of the full OAuth 2.0 process in the implicit grant flow case:

  1. A resource owner opens the registered client app on their device.
  2. The client app contacts the Authorization Server for an access token.
  3. The Authorization Server asks the resource owner to choose an IdP they want to log in with.
    Note: This can either be a third-party IdP or an IdP you set up to store resource owner details. Akamai does not act as an IdP in the API Gateway context. However, if you’re an Enterprise Application Access (EAA) customer, you may use Akamai as your IdP to enable SAML and single sign-on (SSO) authentication for your applications. For more details, see the EAA product page.
  4. The resource owner logs in with the selected IdP.
  5. The IdP asks the resource owner to grant the Authorization Server permissions to use their credentials.
  6. The resource owner grants the Authorization Server permissions.
    Note: At this stage, the resource owner sees the first consent page that lists the scopes the Authorization Server needs to verify the resource owner’s identity.
  7. The IdP provides an authorization code to the Authorization Server.
  8. The Authorization Server asks the IdP to exchange the authorization code for an access token.
  9. The IdP verifies the authorization code and provides an access token.
  10. The Authorization Server asks the resource owner to grant the client app permissions to use their data.
  11. The resource owner grants the client app permissions to use their data.
    Note: At this stage, the resource owner sees the second consent page that lists the scopes the client app needs to interact with the APIs that contain the resource owner’s data.
  12. The Authorization Server provides an access token to the client app.
    Note: The client app receives the access token directly through the user agent that it runs on.
  13. With a valid access token, the client app contacts the resource server again to request the resource owner’s data.
  14. The resource server validates the access token and provides the requested data to the client app.

The client app can make subsequent requests to the resource server until the access token received from the Authorization Server expires, in which case the process repeats.