Why you should stop using the OAuth implicit grant!

No one should any longer use the implicit grant! That’s what IETF’s OAuth working group, the authority for official OAuth specifications, recommends in the upcoming OAuth 2.0 Security Best Current Practice RFC. The decision was met during the IETF meeting this week in Bangkok.

Here is what the working group document says:

The implicit grant (response type “token”) and other response types causing the authorization server to issue access tokens in the authorization response are vulnerable to access token leakage and access token replay …

In order to avoid these issues, Clients SHOULD NOT use the implicit grant and any other response type causing the authorization server to issue an access token in the authorization response.

Sound rather drastic, what’s the reason?

Simply put, the implicit grant’s security is broken beyond repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user’s health record or initiating a payment, from her bank account.

Moreover, increasingly complex and dynamic usage scenarios require an additional security layer called sender constrained access tokens to prevent malicious reuse of access tokens. Unlike bearer tokens, where anyone in possession of a token can use it, sender constrained access tokens require the sender of a request to demonstrate possession of a private key the access token is bound to. Unfortunately, the implicit grant cannot easily be extended to support this more secure token type.

Is this the deathblow for OAuth?

Certainly not since implicit was meant to support browser-based JavaScript apps only. All other client types, such as web or smartphone apps were always recommended to utilize the authorization code grant. Instead of access tokens the authorization code grant issues so-called authorization codes at the authorization endpoint through the browser. They must be redeemed for tokens in a direct HTTPS-secured request with the authorization server’s token endpoint.

This indirection has huge security advantages: Authorization codes can be short lived and one-time use and the authorization server can authenticate the clients, resulting in a significantly reduced attack surface. It also allows to detect all kinds of nasty attacks HTTP redirects are susceptible to, especially injection. The upcoming OAuth Security BCP explains this in detail.

But why the heck did the OAuth working group invent this implicit grant at all?

Well, in the old days (back in 2010) browser-based apps were restricted to sending requests to their server’s origin only. So there was no way to call an authorization server’s token endpoint at a different host. That’s why the short cut was introduced to deliver the access token in the authorization response through the browser. The risks associated with this approach should be mitigated by limiting the privileges and lifetime of such tokens. The implicit grant has always been a compromise!

Thanks to Cross-Origin Resource Sharing (CORS) this compromise now ends. CORS allows browser-based apps to send requests to hosts outside of their origin given the destination permits it. And what’s very important, it’s broadly adopted! This evolution allows the OAuth working group now to recommend use of the authorization code grant for browser-based apps, that way leveraging the aforementioned security benefits to those apps as well.

Work has also started towards a Best Current Practice RFC for browser-based apps. If you want to contribute, please post to the OAuth mailing list.

In my opinion, discontinuing implicit improves OAuth security and makes it simpler since developers no longer need to worry which response type to use. And simplicity is one of the design principles that made OAuth so tremendously successful. Still there are some, some say too many, options but that’s also the reason of OAuth’s demonstrated versatility.