OAuth 2 – Implicit Grant

This is part of a series post about OAuth2. In this post, I go over the implicit grant type and how it relates and differs to the authorization code grant type.

Let’s look at a high-level only flow of the implicit grant flow via an example in which an application recommends a user movies based on the movies the user’s friends like on Facebook.

1. The user submits a request to the Movie app to get movie recommendations.
2. The app redirects the user to Facebook to authenticate.
3. The user authenticates with Facebook and gives consent for the Movie app to access the user’s Facebook data
4. Facebook sends back an access token to the Movie app via a redirect url.
5. The Movie app uses the access token to request the user’s Facebook data on behalf of the user and provide recommendations to the user.

For comparison, here’s the flow using the authorization code grant.

1. The user submits a request to the Movie app to get movie recommendations.
2. The app redirects the user to Facebook to authenticate.
3. The user authenticates with Facebook and gives consent for the Movie app to access the user’s Facebook data.
4. Facebook sends back an authorization code to the Movie app via a redirect url.
5. The Movie app submits another request to Facebook to request an access token,  passing its client credentials ( client id and secret ) as well as the authorization code obtained from step 4.
6. Facebook validates the client’s credentials and authorization code, then issues an access token and optionally a refresh token back to the Movie app.

As you can see at the surface level, the implicit flow is more or less similar to the authorization code flow except it does not have the step of authenticating the client. As we discuss when to choose the implicit grant type vs the authorization grant type , we’ll explore other differences between the two flows and see they are meant for different types of applications.

When should you use the implicit grant type?

Let’s talk first about why we don’t just use the authorization code grant type since it has an extra security step of authenticating the client and thus is more secure. This is because the overhead of authenticating the client offers no additional security benefits for public applications – applications that cannot secure a token. Such applications include native mobile and web applications that use javascript. When those applications pass along a client’s credentials for authentication or requesting an access token, it is not possible to hide the tokens from the resource owner and thus any malicious users. In addition, the authorization code grant type is also meant for server to server communication as it supports requesting a refresh token without a presence of the resource owner, whereas the implicit flow expects the presence of the resource owner for authorization and does not support refreshing an access token.

In summary, you should use the implicit flow if your application cannot hide the tokens from the resource owner or other users who have access to the device.