OAuth 2.0 : Stop repeating yourself

[Source - https://www.toonpool.com/user/997/files/every_four_years_history_repeati_1226535.jpg]

Assume that all your basic information are already stored in a place. Now there is a need for a person to know about you and get something done with your permission. Rather than repeating all those details again what if you ask that person to get the details from that particular place where all your basic details are stored and give permission to access only certain information. Doesn’t this make life easy???

If YES, then congratulations…..!!!!! Welcome to the OAuth club :) This is what OAuth does for you.

An introduction to OAuth

OAuth is a framework to give permission to 3rd party applications to access protected data on behalf of the user. In simple terms, “A framework for delegated authorization”.

OAuth 2.0 provides 2 main services to the end-users as well as the 3rd party applications. The services are,

• Federated Identity — Allowing users to log in to an application with another existing account that the user owns. (End-users)
• Delegated Authority — Allowing another service to access resources in a controlled manner on another service on behalf of the user. (3rd Party Applications)

OAuth framework has 3 versions as of now. They are,

a) OAuth Core 1.0

b) OAuth Core 1.0a (OAuth Core 1.0 Revision A)

c) OAuth 2.0

This blog is based on OAuth 2.0 as it is the most widely used version.

OAuth 2.0 : Open Authentication 2.0

This version of OAuth provides authorization flow for web, desktop and mobile applications. Assume a person has an account in Facebook. The person now wants to access another website called happymeal.com, which is requesting the persons’s details to register the person. So instead of requesting the person to provide all the details and get registered with happymeal.com, the website asks the person if he has a Facebook account. If so then happymeal.com can get the necessary details from Facebook which was permitted by the user and allow the user to login to happymeal.com. This is the overall flow of OAuth. But in reality OAuth is not this simple.

Let’s get into the technical side of OAuth. Before understanding the actual flow of the protected authorization let’s get to know about the structure of OAuth. OAuth has 4 different roles and 4 different grant types. These are like the blocks that create the OAuth building and make it work in real world scenarios.

OAuth Roles

1. Resource Owner
2. Client Application
3. Authorization Server
4. Resource Server

Resource Owner is the person who owns the account or in other words the user. So he will be the person who authorizes the 3rd party application to access his exiting account profile (mostly its the social login profile) with the predefined “scope” limits. So that the 3rd party application can access only a certain type of information of the user from the user’s existing account.

Client Application is the 3rd party application which needs to get user’s approval to get the details from user’s exiting account. In order to get the details from the existing account the client application needs to get registered in the service provider (From whom the client is going to get the user details). So whenever the client application request for details with user’s approval, the service provider knows that the client is a valid client and can give the necessary details.

Authorization Server is the entity that authenticates the client application and provides the necessary tokens to the client in order to get the required resources of the user.

Resource Server is the host of the protected user account. So to get the necessary resources of the user the client will approach the resource server and get it.

OAuth Grant Types

1. Authorization Code Grant Type
2. Implicit Grant Type
3. Resource Owner Password Credential Grant Type
4. Client Credential Grant Type

Authorization Code Grant Type is used with server-side web applications.

Implicit Grant Type Type is used with client-side (single page web applications, mobile applications) applications.

Resource Owner Password Credential Grant Type is used with trusted applications. Mostly with those applications that has both mobile and web versions of it.

Client Credential Grant Type is used by clients to access resources about its own services rather than to access a user’s resources. There aren’t any explicit resource owner available for this grant type.

We will be focusing on the Authorization Code Grant Type with an implemented application example.

Authorization Code Grant Type

Authorization Code is considered as the most secure grant type. This includes all 4 roles and 3 end points in the flow.

3 end points are,

• Authorization end point is in authorization server. The end point through which the client application should communicate to the authorization server to initiate the authorization process.
• Token end point is in authorization server. The end point through which the client application should communicate to the authorization server to initiate the token process.
• Redirection end point is in client application. The end point through which the authorization server sends the access token, refresh token, etc.

The following Figure illustrates the overall flow of the Authorization Code grant type.

Fig 1 - Authorization Grant Type Flow

Let’s take a look at the flow of the grant.

1. GET request to get authenticated : Once the user decided to login to the client application through one of his social logins, the client application requests the corresponding social login to authenticate the client application. At the very beginning the client application should get registered with the authorization server and get the relevant client ID and the client secret.
2. Once the Authorization server receives the GET request, it opens up the login page of the corresponding website(in this case the social media site) and prompts the user to login if he has not.
3. As the result of successful login the user will be prompt with a consent page asking the user to provide permission on the client application requested scope.
4. On a successful scenario the user provides permission to the client application to access the existing account with limited privileges.
5. This approval of access will be notified to the authorization server. The authorization server will generate a code to be submitted to the client application. This is a temporary code indicating that the client application has received the permission to access the user’s account.
6. This code will be sent back to the client application through the authentication end point.
7. The client application now send this code in a POST request along with encoded client ID and client secret through redirection end point.
8. Once the authorization server receives this request it validates and generates the access token and sends it to the client application.
9. The client application sends a GET request to the resource server along with the access token.
10. The resource server validates the request and cross check the access token and the scope that came along in the request. If the request is valid the resource server returns the requested resource to the client application.

Google Drive file uploading application with OAuth 2.0

This is a demo application to show how the flow of OAuth 2.0. This is a file uploading application which stores the uploaded files in Google drive. The roles are as follows:

a. User - Myself

b. Client Application : File uploading application developed in Spring boot

c. Authentication Server : Google Authentication server

d. Resource Server : Google Resource Server

Step 01 : Application Registration

In order to implement such application, the application needs to be registered with the Google service. The following 3 attributes should be given in order to register the application.

1. Application Name
2. Application Website
3. Redirect URL or callback URL is where the user will be redirected after the user authorize the client application.

Once the application is successfully registered, Google will provide the client ID and the client secret. This is something like username and password for the application.

Client ID is publicly exposed for Google to identify the registered application.

Client secret is a private credential used to authenticate the application.

The following images illustrates the basic steps involved in registering the client application.

1. Create a project in Google developer console

Fig 2 - Create a new project in Google developer console

2. Enable Google Drive API to allow the client application to access the resources

Fig 3 - Enable Google Drive API to generate credentials for the client application in order to access the resources

3. Create credentials

Fig 4 - Click on Create Credentials button to create the client ID and the client secret for the application

4. Provide client application details to generate the credentials

Fig 5 - Provide client application details

Fig 6 - Consent page display setup

5. Client ID and client secret

Fig 7 - After the application is registered the client ID and secret can be downloaded

Step 02 : Build the client application

The Google Drive Doc Collector application is developed in Spring boot using the Google Client Library for OAuth and Drive.

At the very beginning the user will be presented with the following page which redirects to the consent page to give required permission from the user.

Fig 8 - Page with the link to to Sign in with Gmail account

When the “Sign in with Gmail” is clicked a GET request will be sent to the authorization server through its authorization end point. The request is sent as follows,

https://accounts.google.com/o/oauth2/auth?
access_type=offline&
client_id=XXXXXXXXX.apps.googleusercontent.com&
redirect_uri=http://localhost:8080/oauth&
response_type=code&
scope=https://www.googleapis.com/auth/drive

The query parameter of the url are,

access_type — Indicates whether the application can refresh access tokens even without user interaction (even in offline).

client_id — The client ID provided to the client application

redirect_uri —Where the user will be redirected after the user authorize the client application

response_type — Expected response type from the server. For Authorization Code, the value is code

scope — A list of scopes that identify the resources that the application could access on behalf of the user

As the result the following page will be presented to the user followed by the consent page.

Fig 9 - Selection of gmail account

Fig 10 - Consent page that request View and manage the files in your Google Drive permission from the user

The corresponding implementation for the aforementioned flows and pages are as follows.

MainController.java

GoogleDriveService.java

index.html

Once the user provides the permission the user will be redirected to the home page where he can upload the files to the Google drive. Each of the request to upload the files will be sent with the access token in the request header to indicate that it has got the permission to upload the files to Google drive. The Header will look something like Authorization:Bearer <access token>. The term bearer indicates that any request with the corresponding access token should be permitted to upload the files to the drive. The home page is as follows,

Fig 11 - Home page

home.html

The complete implementation of the project can be found in Git Link. See you soon in another interesting blog post…