Authorization Basics

3 mins read

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.

Switch To Secure Alternatives

Cloudentity comes with multi-tenant authorization server as a service that supports the Implicit Flow but also all the secure alternatives to this legacy flow.

Launch OAuth Server

Learn More

Implitic 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.

Read More

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

sequenceDiagram autoNumber participant User participant Client application participant Authorization server participant Resource server (API) activate User User->>Client application: Access activate Client application activate Authorization server Client application->>Authorization server: Request authorization note over Client application, Authorization server: The request must contain
the response_type set to
token deactivate Client application Authorization server->>User: Display consent User->>Authorization server: Give consent deactivate User Authorization server->>Client application: Return token deactivate Authorization server activate Client application Client application->>Resource server (API): Call API with token activate Resource server (API) Resource server (API)->>Client application: Return data deactivate Resource server (API) deactivate Client application

A user tries to access the application (the client).
The client sends an authorization request to the authorize endpoint.

The client must inform Cloudentity 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.
Sample call to the authorize endpoint with Cloudentity as an authorization server
```
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"
```
Cloudentity displays a consent screen for the user.
The user gives their consent.
Cloudentity 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.

Updated: Sep 8, 2023