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.
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
noneand 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
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.
To know more about threats that come with the use of the implicit grant flow, read the following documents:
RFC6749, section 10.16 - it explains the potential misuse of access tokens to impersonate the resource owner in implicit flow.
OAuth 2.0 Security Best Current Practice, section 2.1.2 - it provides security best practices and recommendations for the implicit grant.
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.
A user tries to access the application (the client).
The client sends an authorization request to the authorize endpoint.
The client must inform ACP of its desired grant type by using the
response_typeparameter. For the implicit grant flow type, the value of the
response_typeparameter must be
ACP displays a consent screen for the user.
The user gives their consent.
ACP returns the token embedded in the redirection URI.
The client requests protected resources from the resource server and presents the token it received in the previous step.
The resource server validates the token and responds with requested resources.