Why OAuth2 is not for authentication.

If you are like me, you might have thought OAuth 2 is for both authentication and authorization. After all, the main OAuth 2 flows ( Authorization Code, Implicit, User Credentials ) all require a resource owner to authenticate against an authorization server.  In this post, I’ll talk about some of the reasons I’ve learned why OAuth 2 is not for authentication.

No standard endpoint to retrieve a user’s identity.

If you need to provide clients a way to retrieve a user’s identity, you’ll need to define your own API/endpoint because OAuth 2 standards do not define how to retrieve a user’s identity.  Having to define the custom endpoint makes interoperability with other systems difficult, especially if your platform needs to interact with a considerable number of clients. For instance, a client would not be able to utilize a general OAuth 2 library to fetch the user’s profile since each API is likely different in terms of fetching a user’s identity as there is no standards.

Access token does not imply user authentication.

An access token in its simplest form only represent authorization to access specific resources; it does not contain the user’s identity or authentication. In other words, an attacker who has access to an access token representing authorization for accessing a specific user’s resources may impersonate the user without the victim’s realization or presence. Furthermore, if multiple client applications connect to a same authorization server, and if the attacker has access to an access token which the authorization server issues to one client, the attacker can access that client as well as any other clients that talk to the same authorization server. I myself had experienced this kind of vulnerability. In a security model I worked on before, we had a client web application and several backend applications; all of them talk to the same authorization server.  As long as the authorization server has issued an access token for one of the applications, the attacker can call any of the applications on behalf of the user, regardless of whether the user has explicitly authenticated and granted that application access. In addition, a client application can request a refresh token using an access token without requiring the user to authenticate.

Therefore, having an access token does not imply having the user’s authentication.

OAuth 2 is an authorization framework.

The title of the specs – “The OAuth 2.0 Authorization Framework” suggests it is a protocol for authorization. The specs do not mention or suggest in any way that one should use OAuth 2.0 for authentication. As authentication is not a first class citizen in OAuth 2, the specifications lack the standards to make OAuth 2 a secure framework for authentication.  The various extensions of OAuth 2 to make it useable for authentication furthers muddy the water, creating the illusion that OAuth 2 is an authentication framework. For instance, Facebook provides a custom endpoint to inspect an access token and confirm identity of a user for its Facebook Login.

Conclusion

You should definitely understand the threats associating with using OAuth 2, especially  when using it for authentication. A good reference is The OAuth 2.0 Threat Model and Security Considerations, which not only describes the threats but also suggests ways of safeguarding against them.

If you are working on a new system, instead of providing custom extensions, look at Open ID Connect, which is a protocol based on top of OAuth 2 that also supports authentication. For existing applications that use OAuth 2, discuss about the security threats with your boss or subject matter experts in your organization and try to address them promptly to protect the company, applications and users’ identities.

References:

• OAuth 2.0 Threat Model and Security Considerations.
• User authentication with OAuth 2.0.
• The problem with OAuth for authentication.
• Facebook Login – Manually build a login flow. 

• “OAuth 2.0 – Looking Back and Moving On” – video by Eran Hammer.