Open ID Connect Authentication With OAuth2.0 Authorization

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.

OAuth 2.0 is used by tech giants like Facebook, Google, and Twitter. It allows 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. The question here is: are they right in doing that?

Is OAuth 2.0 an Authentication Protocol?

The answer is no, but before we go into all of the specifics, let's take a look at some basic concepts. 

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: Resource Servers host resources of different users.

Client: It is the application accessing the resource server.

Authorization Server: It is the server issuing access tokens to the client after successful authorization.

OAuth 2.0

The OAuth 2.0 specification defines a delegation protocol that provides clients with “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 with 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, the resource server and authorization server are the same. The flow of OAuth 2.0 is explained below:

OAuth 2.0 is used in a wide variety of applications, be it web 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 an authentication protocol. Here, they are making a big mistake.

Not an Authentication Protocol 

A full authentication protocol will provide you with 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. 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 sends none of this to the application; it only asks for an 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 a user there at all.

Although it isn't technically an authentication protocol, it is possible to use it to build one. Tech giants like Google, Facebook, and Microsoft were doing it prior to 2014. However, they faced issues, as there were custom hacks on the top of OAuth 2.0 to get users' information. Because there is no standard way of getting user information in OAuth 2.0, all these implementations were different from one another, and, therefore, they were not inter-operable.

As a solution, developers added an extension on top of OAuth 2.0 to get the missing functionality required for authentication. Why do all of this on top of OAuth? Why not create a separate protocol for authentication? 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 when added functionality could make it an authentication protocol.

OpenID Connect for OAuth 2.0

OpenID Connect is an identity layer developed on top of the OAuth 2.0 protocol. It lets clients confirm the identity of and receive basic profile information about the end-user based on the authentication done by using an authorization server. App and web 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).

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

ID Tokens

The OpenID Connect's ID Token is a signed JSON Web Token (JWT). This contains a set of information about the authentication session, including identifiers for the end-user, the identity of the provider who issued the token, and the client for which this token was created. The client parses the content of the ID Token and obtains the user’s information. The ID Token is issued in addition to an access token. This allows 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 that helps in preventing impersonation attacks. (I.e., the client 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 (e.g. user info, which contains information about the current user in case the information provided by ID token is not enough). The information provided by the 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 a set of standardized scopes: OpenID, profile, email, address, and 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.