OAuth 2.0 Demystified

OAuth is a delegated authorization framework that allows an application to access protected resource without asking for user’s credentials that own’s the resource. It was developed as a specification to standardize the process for applications to gain access to user’s data or for services to authorize access to other services (API authentication and authorization). OAuth by itself is only an authorization framework, however it can be extended to provide authentication by using OpenID connect.

In this post, we’ll look at the terminology used in OAuth 2 and also understand how OAuth 2 flow works at a high level.

OAuth 2 Terminology

• Resource Owner: It’s the user who owns the data and authorizes the client application to access the data on their behalf
• Client: The client refers to the application that wants to access protected resource on the server. The client application needs to get the authorization from the resource owner before it can access user data.
• Authorization Server: It’s the system that grants authorization to client for accessing protected resource on the server.
• Resource Server: It’s the system that hosts the protected resource which the client application wants to get access.
• Authorization grant: It’s a credential that represents resource owner’s authorization to access its protected resources. Authorization grant is used by the client application to obtain access token.
• Access token: It’s the token used by client when accessing protected resource on the server. They are meant to be short lived and can be generated by authorization server using the authorization grant.

Why is OAuth needed?

In a client-server authentication model, the client requests access to a protected resource on the server by authenticating to the server using resource owner credentials. However, when a third party application wants to access the resources on behalf of resource owner, there is no secure way to grant access to protected resources unless resource owner trusts the third party application and shares it’s credentials with the third party.

OAuth addresses these issues by introducing an authorization layer that separates the role of the third party client application from the resource owner. The client application doesn’t need to know the resource owner credentials in order to access protected resource on the resource server. Instead, the client application gets an access token after proper authorization by the resource owner using which it can access protected resources on the server.

OAuth specification defines four grant types i.e. the credentials representing the resource owner’s authorization to grant client access to it’s resources.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

In this post, we’ll take a closer look at OAuth flow with Authorization Code grant type.

OAuth 2 – Authorization Code Flow

The Authorization Code grant type flow works by having the client application make a request to authorization server with the response type as authorization code. The request also includes the scope requested by the client application and a redirect URL which is used for callback by authorization server after resource owner is authenticated by authorization server.

As we can see in the flow above, the client application makes a request to authorization server with an authorization code grant type. After the consent is granted by resource owner to allow client access to it’s resources, an authorization code is generated which is then used by the client application to obtain an access token. The access token is then used by the client application in all the API calls to get access to the resource server.

There are two types of channels involved in this flow.

• Back channel – It’s a highly secure channel on which a server communicates with another server.
• Front Channel – It’s a less secure channel which involves communication with the browser.

The request from the client application and the redirects using the callback URI in the authorization code flow happens over the front channel. There is a possibility that an attacker can get hold of the authorization code (on the front channel) which then can be misused by the attacker to get access to protected resources. This is mitigated by having the client application exchange authorization code for access token on the back channel. Since the access token is obtained on the back channel, it’s considered to be safe for granting access to protected resources. This explains why an extra step is needed to get the access token in exchange of authorization code. The authorization flow grant type utilizes both the front channel and back channel to provide delegated access to client application.