What Are OAuth 2.0 Grant Types? Part 2: Implicit Flow

There are four grant types in OAuth 2.0—authorization code, implicit, resource owner password credentials and client credentials—and which one you should use will depend on the use case. I've covered authorization code in a previous post, and now it’s time for another important and useful grant type that’s very different: the implicit grant type. 

You may recall from my earlier post that authorization code flow is the best possible flow for security, and if you can use it, you should. But there are going to be situations where time efficiency is paramount. That’s where implicit flow comes in, because it is designed for lightweight applications. With the explosion of Angular, React.js, other frameworks, and the ease with which you can make SPA’s (Single Page Applications) or client-side rendering apps,  keeping things lightweight and fast are important considerations and the security concerns are covered.

The key distinction between how these two flows work is that implicit flow skips a step taken by the authorization code flow. This blog will focus on the subtractions made to the overall abstract flow, so it’s a good idea to be somewhat familiar with the different roles (even if it’s just knowing there are different roles) and the overall path.

The word “implicit” comes from the implicit authentication we get from the client, which occurs through the use of the resource owner and redirection URI. When the authorization server issues an access token, it doesn’t actually authenticate the client, and no intermediate credentials are issued in order to obtain the access token. Instead, when it comes to the client (the one running around requesting stuff), we draw the conclusion that the client is who they say they are because we’ve gotten the resource owner to grant access—and we only send the token that represents access to a predetermined place.

The best way to understand the steps involved in implicit grant flow is to compare this grant type to the authorization code flow grant type. In short, implicit grant type flow skips a step. Or, another way to think of it is that implicit flow consolidates two steps that the authorization code grant type takes:

Because the implicit grant lowers the round trips required to obtain an access token, the flow can improve the speed/responsiveness of some clients. Specifically, it can be useful in the following cases:

• Your app runs in a browser or client-side. Resources are limited when your code runs in the browser, or we might not be able to assume the client has some significant level of resources. 

• You’re known to own a site that can be used as a redirect URL. The implicit grant flow makes use of redirect url for security. The redirect url is registered with the authorization server beforehand by a developer or admin, so the admin has control over where the access token is sent.

• You don’t need refresh tokens. If you don’t need to get new access tokens after the old ones have expired, you may not need refresh tokens. However, you can get another access token by restarting the implicit flow.

• Client interacts with user-agent, browser or the thing the user is interacting with.

• You need to optimize for speed. You might have users on a slower network connection or your app itself takes a decent amount of time to process, so you don’t want to waste time and resources on the extra call to the authorization server.

But keep in mind that this efficiency may come at the cost of security. Be sure to carefully consider any security implications, especially when the more secure authorization code grant type is available. 

In future posts, I’ll take a look at the two remaining OAuth 2.0 grant types. Until then, I invite you to test out PingOne for Customers with a free trial!