Simple OAuth 2.0

Consuming Google API using OAuth 2.0

This blog post will discuss an introduction to OAuth 2.0 and will guide you on how you can implement the OAuth flow in order to consume the Google API from your application.

What is OAuth 2.0?

In simple word, OAuth is,

"OAuth (or Open Authorization) is a framework that gives users the ability to grant access to their information stored in one place, from another place."

OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and Google. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.

This blog is going towards application developers and provides an overview of OAuth 2 roles, authorization grant types, use cases, and flows.

OAuth Roles

Resource Owner: User

The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. read or write access).

Resource / Authorization Server: API

The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.

From an application developer's point of view, a service's API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.

Client: Application

The client is the application that wants to access the user's account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

The Flow

Here is a more detailed explanation of the steps in the diagram:

1. The application requests authorization to access server resources from the user.

2. If the user authorized the request, the application receives an authorization permissions.

3. The application requests an access token from the authorization server by presenting authentication of its own identity, and the authorization permissions.

4. If the application identity is authenticated and the authorization permissions are valid, the authorization server issues an access token to the application. Authorization is complete.

5. The application requests the resource from the resource server and presents the access token for authentication.

6. If the access token is valid, the resource server serves the resource to the application.

The actual flow of this process will differ depending on the authorization grant type in use, but this is a general idea. We will explore different grant types in the following section.

Grant types

In the above flow, the first four steps cover obtaining an authorization grant and access token. The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the API. OAuth 2 defines four grant types, each of which is useful in different cases:

• Authorization Code: used with server-side Applications

• Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)

• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself

• Client Credentials: used with Applications API access

we can say those are four different versions. Or, more correctly, four different flows. OAuth 2 is the totality of these flows. It’s not mandatory to implement them all, but only the ones that you need.

The goal remains always the same: to obtain an access_token and use it to access protected resources.

Before going to deep with these grant types we need to focus on the EndPoints :

Endpoints

• Redirection Endpoint — This is provided by the Client Application to the service provider. The service provider will send the access tokens etc to this endpoint.

• Authorization Endpoint — This is the endpoint the Client Application should use to initiate the Authorization process.

• Token Endpoint — This is the endpoint the Client Application should use to initiate Token flow.

Now we can describe grant types in more detail, in the following sections.

      1. Authorization Grant Type

1. The application (Client) sends an authorization request to the Auth Server (Authorization Endpoint).

2. Auth Server requests the user for his/her consent for the Application (Client) to access the claims it requests.

3. If the user grants consent, Auth Server provides an Authorization Code grant to the Client Application. (Redirection Endpoint).

4. Client Application sends an Access Token Request to the Auth Server along with the Authorization Code provided previously. (Token Endpoint).

5. Auth Server provides the Access Token (which expires after a specified time period) and Refresh Token to the Client Application to access the claims requested before.

6. If the Access Token expires, Client Application sends a request to the Auth Server (Token Endpoint) along with the refresh token and request for a new Access Token.

      2. Implicit Grant Type

This flow is implemented by applications that run on the Client side (i.e: Javascript).

1. This flow will follow the same 1) and 2) steps in Authorization Grant flow but in the Authorization Request it will mention ‘token’ as the response type, whereas in the previous flow it was ‘code’.

2. If the user grants consent, Auth Server redirects the user-agent to the redirect URI provided by the Client Application that contains a URI fragment containing the access token.

3. User-agent follows the redirect URI retaining the access token

4. The application sends a script to the user agent that can extract the access token.

5. User-agent runs the script and returns the token to the Application.

     3. Resource Owner / Password Credentials Grant Type 

With the resource owner password credentials grant type, the user provides their service credentials (username and password) directly to the application, which uses the credentials to obtain an access token from the service. This grant type should only be enabled on the authorization server if other flows are not viable. Also, it should only be used if the application is trusted by the user (e.g. it is owned by the service or the user's desktop OS).

After the user gives their credentials to the application, the application will then request an access token from the authorization server. If the user credentials check out, the authorization server returns an access token to the application. Now the application is authorized!

      4. Client Credentials 

The client credentials grant type provides an application a way to access its own service account. Examples of when this might be useful include if an application wants to update its registered description or redirect URI or access other data stored in its service account via the API.

The application requests an access token by sending its credentials, its client ID and client secret, to the authorization server. If the application credentials check out, the authorization server returns an access token to the application. Now the application is authorized to use its own account!

Now, let’s implement a sample application that uses OAuth 2.0 Authorization Grant flow to allow users to browse their Google Drive Files.

So let’s get a start! The following Images shows all the steps associated with this flow.

Step 1 - Registering the Client App in Google Console Website

The first step is to create an application in the Google console account. Visit https://console.developers.google.com and add a new project.

Then enable APIs 

Set credentials - O auth Client Id For Web application

Before creating credentials you should have to prepare Oauth user concent screen 

Now You can create Wen application credentials; In there  You should have to give Authorized redirect URIs To receive Auth code.

If you successfully complete the above steps, You can get your O auth client id and secret as follows.

Step 2 - Obtaining the Authorization Code

In order to obtain the authorization code from Google, we need to send an HTTP POST request to the Authorize Endpoint of google, which is https://accounts.google.com/o/oauth2. Along with the request, you need to send several parameters which are described below.

sample request:

https://accounts.google.com/o/oauth2/v2/auth?client_id=610790991984-vikl8floe280nheoau5e016r1le7l78m.apps.googleusercontent.com&response_type=code&scope=https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/plus.me&redirect_uri=http://localhost/googleapis/drive/process.php&access_type=offline

If you are not logged into Google in the browser, first it will ask you to log in,

Once you log in, it will show the following popup. We call this the “User Consent Page” in OAuth terminology. In there, it will show what are the resources from the user account that this external app would be able to access on behalf of you.

Once you Continue, Google will redirect the browser to the Redirection Endpoint URL which you defined in the app settings and along with the URL, it will send the query parameter code, which is the authorization code. If you had a client website, you can extract this parameter value from the web app itself.

sample response url :

http://localhost/googleapis/drive/process.php?code=4/hAAh4U0g4ADM1TQkvTrVOE-KikP9fbk8j-wgS1XQ1cREeqsZfyZXv_9gRCBkXQjlUyOmi3iyvZhr_uVJutpylSY&scope=openid%20https://www.googleapis.com/auth/drive%20https://www.googleapis.com/auth/drive.metadata.readonly%20https://www.googleapis.com/auth/plus.me

Step 3 - Obtaining the Access Token

Now that we have got the authorization code, the next step is to request an OAuth access token from Google, which can be used to access user resources (permitted with the scopes which we requested). For that, the client web application has to send an HTTP POST request to the Token Endpoint of google sending the authorization code received in the previous step. The Token Endpoint of Google is https://googleapis.com/oauth2/v4/token.

Now you can receive Access token :

Step 4 - Retrieving User Resources from Google, providing the Access Token

Response:

Now we can happily Fetch drive and user data on google...  😁

You can find my application implementation From :  
Simple-OAuth-2.0 Github project