OAuth Implicit Flow

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.

What Implicit Flow Is

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.

Implicit Flow 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.

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.

How Implicit Flow Works

A user tries to access the application (the client).
The client sends an authorization request to the authorize endpoint.
The client must inform SecureAuth 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.
See the sample call to the authorize endpoint with SecureAuth as an authorization serve
```
curl --location \
--get \
--url "https://$TENANT_ID.$REGION_ID.authz.cloudentity.io/$TENANT_ID/$WORKSPACE_ID/oauth2/authorize" \
--data-urlencode "response_type=token" \
--data-urlencode "client_id=$CLIENT_ID"
```
SecureAuth displays a consent screen for the user.
The user gives their consent.
SecureAuth 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.

In this section: