In the previous decade, Open Authorization (OAuth) has emerged as an industry-standard protocol for authorization. Today, almost, every web application, mobile application uses OAuth 2.0(latest version of OAuth) for Authorization. According to Wikipedia, OAuth 2.0 is an open standard for delegated Authorization. It’s usually used as a method for Internet users to get their websites or applications allow and provides access to their information on other websites without giving them the passwords. OAuth 2.0 is used by tech giants like Facebook, Google Twitter, etc. to allow the users to give information about their accounts with third-party applications or websites. It is also used to provide mechanisms for user authentication. So, this has led many developers and API providers to incorrectly conclude that OAuth is itself an authentication protocol and, thus, they use it to perform Authentication. But the question here is, are they right in doing that?

Is OAuth 2.0 an Authentication protocol?

I am not going to keep you in suspense. So, the answer is a straightforward NO. I bet you got surprise after knowing that. Now, this answer has raised a lot of questions in your mind like Why? What is the reason? Also, if OAuth 2.0 is not an authentication protocol, then, what is? What should we use for authentication? At this point, I can only say that this blog will answer all your questions. So, just take a leap of faith and read it to the very last.

But before we begin. Let’s get a brief of some basic concepts.

Authentication: Authentication means verifying that someone is indeed who they claim to be and, whether they are logged in or not.

Authorization: Authorization means deciding which resources a user can access, and what they should be allowed to do with those resources.

Resource Owner: The owner of the resource.

Resource Server: It hosts resources of different users.

Client: Application accessing the resource server.

Authorization Server: The server issuing access tokens to the client after successfully authorization.

Now, As, we have got a brief of those. So, let’s begin.

OAuth 2.0

The OAuth 2.0 specification defines a delegation protocol that provides to clients a “secure delegated access” to server resources on behalf of a resource owner(user). Basically, it specifies a process for users to authorize third-party, to access their server resources without sharing their credentials. It is meant to work with HTTP and allows the authorization server to assign access tokens to third-party clients, by the approval of a special resource owner. The client’s back channel (application server) then uses the access token to access the protected resources that is hosted by the resource server. In most cases, Resource server and Authorization server are same. The flow of OAuth 2.0 is explained below:

OAuth 2.0 is used in a wide variety of applications, be it web applications or mobile applications. It is also used for providing mechanisms for user authentication. This has led many developers and API providers to incorrectly conclude that it is itself an authentication protocol. Now, here they are making a big mistake.

OAuth 2.0 is not an authentication protocol

Why? Because a full authentication protocol will provide you a lot of information about the end user, such as a unique identifier, an email address, and what to call the user when he/she opens the application for example, an application displaying “Hello <user’s name>” on opening. It is all about the user and their presence within the application, and an internet-scale authentication protocol needs to be able to do this across network and security boundaries.

However, OAuth 2.0 indicates the application none of this. It says absolutely nothing about the user, nor does it say how the user proved their presence. It only asks for access token, gets the token, and eventually uses that to access some API. It doesn’t even know anything about who authorized the application or if there was even a user there at all.

OAuth 2.0, itself is not an Authentication protocol. But, yeah, it’s possible to use it to build an authentication protocol. The tech giants like Google, Facebook, Microsoft etc, was doing it pre 2014 , but the problem is that they had added some kind of custom hacks on the top of OAuth 2.0 to get user’s information as there is no standard way of getting the user’s information in OAuth 2.0. And, because of that, all these implementations were different from one another, they were not inter-operable, which is bad for developer’s community. So, the solution, bunch of intelligent people find to all these problems is to add extension on top of OAuth 2.0 to get the missing functionality that it requires for Authentication. But, Why on top of OAuth? Why not create a separate protocol for Authentication? And, the answer is, because OAuth 2.0 already solves the delegation Authorization problem very well and, it is close to act as an Authentication protocol. So, why to create a new protocol. Instead, just add the functionality it requires for Authentication.

OpenID Connect: A standard for user authentication using OAuth 2.0

OpenID Connect is an easy identity layer developed on top of the OAuth 2.0 protocol. It lets clients confirm the identity of the end-user based on the authentication done by an Authorization Server, as well as to receive basic profile information about the end-user in an interoperable and REST-like manner. OpenID Connect uses OAuth 2.0 under the hood to perform Authentication. Application and website developers use it to authenticate users without taking the responsibility of storing and managing passwords. It even provides the functionality of Single Sign-On (SSO). Do keep in mind that OpenID Connect is not really a new protocol, it is just an extension to OAuth 2.0.

OpenID Connect makes standard authentication possible by adding several key components on the OAuth 2.0(base layer):

ID Tokens

The OpenID Connects ID Token is a signed JSON Web Token (JWT) which contains a set of information about the authentication session, which basically includes identifiers for the end user, identity provider who issued the token, client for which this token was created. It serves as security token. The client parses the content of the ID token and obtain the user’s information. Furthermore, an ID token is issued in addition to an access token, thus, allowing the access tokens to remain opaque to the client as it is in OAuth. The Authorization Server signs the ID token with a private key which helps in preventing impersonation attacks i.e., the client performs verifies whether the ID token is modified or not.

User authentication

OpenID Connect enables handling a user’s login or determining whether a user is logged in already.

User Info Endpoint

OpenID Connect defines a standard protected resource i.e., /user info which contains information about the current user if in case, the information provided by ID token is not enough. The information provided by user info endpoint is not part of the authentication process. This resource can be accessed by using access tokens.

OpenID Scope

OpenID Connect also defines set of standardized scopes: OpenID, profile, email, address, phone. The OpenID scope is a special scope, that switches on, the issuance of the ID token as well as access to the User Info Endpoint by the access token. The OpenID Connect scopes can be used with other OAuth scopes without any conflict.

The flow of OpenID Connect is explained below.

As, you can see above, in exchange of Authorization code, the client receives an ID token in addition to access token from the Authorization Server. Thus, providing a standard way to get user’s information as compared to using OAuth 2.0.

Conclusion

So, to summarize, the arrival of OpenID Connect has standardized the whole Authentication process (with the inclusion of ID token and user info endpoint), which was earlier done with custom implementations using OAuth. And, please, don’t think OpenID Connect as a replacement or newer version of OAuth 2.0. While, OAuth 2.0 is a standard for authorization, OpenID Connect enables authentication use cases. Thus, leveraging the OAuth 2.0 protocol. It means that OpenID Connect is a superset of OAuth 2.0. In fact, OpenID Connect itself is built on top of OAuth 2.0.

Those who knew this from the very start, Thank You for your patience. And those, who didn’t know about that. Congratulations, you just got wiser. You’ve also noticed that I didn’t include any piece of code in this blog. The reason for that is because the design decisions are still more important. So, from now, just take an oath that you will not misuse OAuth 2.0 for performing Authentication and will only use it for performing what is meant to do, i.e. Authorization. And, as far as, Authentication is concerned, we will use OpenID Connect for that.