What’s Wrong With the OAuth2 Implicit Grant?
The Implicit grant is part of the OAuth 2 RFC, but is one of the features omitted in the OAuth 2.1 specification. With this grant, you don’t have to write server side code. Instead of having to exchange an authorization code for an access token, you are provided an access token on redirect.
This is convenient if you are working in the JAMstack or in another situation where you don’t want to run a server.
However, it is horribly insecure, broken, deprecated, and should never, ever be used (ever). Okay, maybe that’s being a bit dramatic, but please don’t use this grant. The good folks behind the OAuth 2.1 draft agree, which is why they left it out of that new specification.
The Implicit grant (“response_type=token”) is omitted from this specification as per Section 2.1.2 of OAuth 2.0 Security Best Current Practices
Instead of showing you how to use this grant, let’s discuss why you should avoid it.
The reason that it has been removed is that it skips an important step that allows you to secure the tokens you receive from the OAuth server. This step occurs when your application backend makes the call to the Token endpoint to retrieve the tokens.
Unlike the Authorization Code grant, the Implicit grant does not redirect the browser back to your application backend with an Authorization Code. Instead, it puts the access token directly on the URL as part of the redirect. These URLs look like this:
The token is added to the redirect URL after the
# symbol. This places it in the fragment portion of the URL. What this means is that wherever the OAuth server redirects the browser to, the access token is accessible to any code running in the browser. In other words, to basically everyone.
Let’s take a dummy example of a single-page web application that uses the Implicit grant:
- The code for the application itself (
- A library we found online that did something cool and we just pulled it in (
Let’s assume that our code is 100% secure and we don’t have to worry about it. The library we pulled in, however, is an unknown quantity.
<script> tags. Therefore, we have very little chance of ensuring every other line of code from third-party libraries is secure.
If a third-party library wanted to steal an access token from our dummy application, all it would need to do is run this code:
Three lines of code and the access token has been stolen. As you can see, the risk of leaking tokens is far too high to ever consider using the Implicit grant. This is why we recommend no one ever use this grant.
How to correctly use OAuth in a SPA
Well, if you are building an awesome React, Angular, Vue or other single page application, what should you use instead of the Implicit grant?
Use the Authorization Code grant! It’s secure, safe, well tested, standardized and keeps tokens out of the URL.
In addition to using that grant, take these steps to secure your SPA OAuth flow:
- Use PKCE in your SPA to make sure your application, which can’t maintain a secure client secret, is not susceptible to an authorization code interception attack.
- Run a server. It needn’t be complicated. In fact, it can be as simple as a few lines of node to exchange the authorization code for an access token. Here’s an example Node application. This is also known as the BFF, or Backend For a Frontend, pattern.
Want to learn more about the different OAuth grants? Check out The Modern Guide to OAuth for an in-depth look at all the different OAuth grants and how you might use them in the real world.
Originally published at https://fusionauth.io.