ACP implicit grant flow type

This article explains what the implicit grant flow type is and how it works. It provides information why the implicit grant flow is not recommended.

Warning

Using the implicit grant flow type is not recommended due to its security vulnerabilities. Instead, it is recommended to use the client authentication method set to none and with the use of Proof Key of Code Exchange. To know more about this method, read the client authentication set to none and with the use of PKCE documentation.

In a nutshell

The implicit grant type was created for public clients, like mobile applications or pure JavaScript front-end applications. It does not include client authentication, but, instead, the client receives access tokens as the result of authorization. The implicit grant type does not support granting refresh tokens.

Threats

As there is no client authentication present in the implicit grant flow, the process relies on the presence of the resource owner and the registration of the redirection URI. Access tokens are embedded in the redirection URI and can become exposed to the resource owner or other applications that are used on the same device as the client.

Read more

To know more about threats that come with the use of the implicit grant flow, read the following documents:

Prerequisites

To use the ACP implicit grant type, the client must match the following criteria:

  • The client is registered in ACP with the implicit grant flow.

Process

Implicit grant type diagram

  1. A user tries to access the application (the client).

  2. The client sends an authorization request to the authorize endpoint.

    The client must inform ACP of its desired grant type by using the response_type parameter. For the implicit grant flow type, the value of the response_type parameter must be token.

  3. ACP displays a consent screen for the user.

  4. The user gives their consent.

  5. ACP returns the token embedded in the redirection URI.

  6. The client requests protected resources from the resource server and presents the token it received in the previous step.

  7. The resource server validates the token and responds with requested resources.