Implicit Grant Flow for Client-Side Apps¶

DEPRECATED

Due to a number of security vulnerabilities in the OAuth2 Implicit flow, support for this flow has been deprecated. Please use the OAuth2 Authorization Code flow as described here.

For additional details please review the OAuth 2.0 Security Best Current Practice document. While it is possible to just search this document for issues with the implicit grant flow, a complete review of this entire document is highly recommended.

Finally, here is the conclusion of the IETF OAuth2 working group chair summarizing the working group discussion on this topic.

Implicit Grant

The implicit grant (response type “token”) and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay as described in Section 3.1, Section 3.2, Section 3.3, and Section 3.6.

Moreover, no viable mechanism exists to cryptographically bind access tokens issued in the authorization response to a certain client as it is recommended in Section 2.2. This makes replay detection for such access tokens at resource servers impossible.

In order to avoid these issues, clients SHOULD NOT use the implicit grant (response type “token”) or any other response type issuing access tokens in the authorization response, such as “token id_token” and “code token id_token”, unless the issued access tokens are sender-constrained and access token injection in the authorization response is prevented.

A sender constrained access token scopes the applicability of an access token to a certain sender. This sender is obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g., a resource server).

Clients SHOULD instead use the response type “code” (aka authorization code grant type) as specified in Section 2.1.1 or any other response type that causes the authorization server to issue access tokens in the token response. This allows the authorization server to detect replay attempts and generally reduces the attack surface since access tokens are not exposed in URLs. It also allows the authorization server to sender-constrain the issued tokens.```