Everything about OAuth 2.0: Part 1

In Part 1, I will cover a high-level overview of OAuth 2.0 and Authorization Code grant type.

What is OAuth?

OAuth (Open Authorization) is a framework that defines how a third party application can access a user’s protected resources. You might have seen a lot of websites where you can sign up or log in to their application using Login with Google, Facebook, Twitter etc. These sites use OAuth to handle authorization (and authentication also) using these services. In this series of articles, I will be going deeper into explaining how this works underneath.

Terminologies

Before we get started let’s understand the different terminologies that are used.

• Resource: user info which a third-party app wants access to.
• Resource Owner: owner of the resource which is being requested. The owner can authorize access to a protected resource.
• Client: a third party application that is trying to access the protected resource.
• Authorization (OAuth) Server: it authorizes the client to access the protected resource that is being requested.
• Resource Server: it has the data that is being requested by the client. In some cases, the Authorization Server and Resource Server might be the same.
• Redirect URI: the URL to which the authorization server redirects to once it is authorized.
• Authorization Code: the code received back from the authorization server
• Access Token: the token which the client can use to get the protected resource from the resource server
• Scope: this contains a list of permissions that the client is asking for
• Client Id: unique Id of the client which is obtained when registering third party application in the Authorization Server.

Don’t worry about these terms at the moment. Just understand what these terms mean on a high level. I will be talking about those when I come across them.

Grant Types

There are different ways in which a third party app can request access to a protected resource, and these are called grant types. OAuth 2.0 has 4 different grant (flow) types:

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

I will go through the Authorization Code flow first since that’s a common use case.

Authorization Code

This grant type is used most commonly in mobile and web apps. Following are the steps followed in this flow type:

Request user’s permission

The process starts when the browser sends a request to the Authorization Server. This request is made when the user clicks on any of the `Sign in with` buttons (Sign in with Google, Facebook etc.). Consider the following request for example

• response_type: mentions the grant type to be used. In this case, it’s the Authorization Code grant type.
• client_id: this is obtained when creating an app in the authorization server.
• redirect_uri: the redirect URL once it is authorized by the authorization server.
• scope: this list mentions what is the scope of permissions requested by the client. Here, it is requesting for profile and contact information of the user.

User authorizes the request

Once the request is made the user will be seeing a page that asks for users’ login credentials (credentials of the OAuth service provider)

The user will log in here, and then they will be presented with another page asking the user whether they want to allow access to those resources or not. Now you might feel that this extra step asking the user to acknowledge again is unnecessary since the user has already authenticated. But the reason this is shown is that the client can request access to different scopes of user information. For example, adding contacts to the scope will the give client access to users contact information. As an end-user I will not know what are the scopes the client has requested for. So in this page, clearly mentions a list of actions that the client can perform once the access is given. For example, you might want to give view access to your contact information but not modify or delete it. This page mentions what the client is capable of doing once you allow access to it.

Redirect back to the application

Now after allowing access, the authorization server redirects back to the redirect URL that was provided at the start of the request. Along with this, an authorization code is also provided. The redirect URI should look something like this

Get Access Token

Now using this code, the client sends a request to the authorization server to get an access token in return. The client stores this access token and uses it every time to request the protected resource from the resource owner.

This is the general flow of Authorization code grant type. There can be some minor differences between different an OAuth providers based on their specific implementations.

This was part 1 of the article. In the next part, I will cover how to create a OAuth app to access Google APIs.