Introduction to OAuth Framework

You must have heard this word Oauth if you are from a development background. It is because of its popularity, in a few past years technology has evolved a lot and so the security. With increasing concerns of security, a lot of frameworks and patterns came into the picture and Oauth was one of them. When developers started using Oauth, they found it very secure and useful, and with increasing popularity, so many organizations started using this. 

Now, you will notice that millions of applications are now powered by the Oauth authorization framework. It's important that you know what it is all about and I think that's why you are reading this article.

Let's get started without talking much. Oauth stands for open authorization which simplifies that allowing third-party applications to access the resources available on different servers or applications. But Oauth provides the requesting server a limited amount of access to the resources.

How Does It Work?

To make it easy, let's understand this with an example. you went to a site something.com and you wanted to upload your CV there but you had your CV in your google drive account and you saw there the site had an option to upload from your google drive account but you didn't want to share your google drive credentials with the third-party application so what it did, it took you to the google login page and you logged in then google will ask that this site want to read this information do you authorize? You said, I do, and then google issues a code through which they can only perform limited requests for which you've authorized them. This ensures your personal information security and in earlier days we used to share our credentials with the third-party applications and then the third-party application used to make the request to get authorized which is in reality very insecure, you never would want to get hacked.

What happens behind the scenes, the third-party application registers itself with google so that it can authenticate users from google servers, the third-party application takes you to the google and says hey google, please check if you have this user registered? Google checks your details and says, yes I have. Third-party application - I wanted to access some of the user information. Google says, let me ask the user if they want you to see that, and google asks the user, do you want this third party app to access these permissions and if you click on authorize then google gives an access token to third party app through which they can access the protected resources that you have authorized them to access. 

Oauth Terminologies

OAuth defines a few terms using which we address third party app and your data as well as you. They are 

• Resource Owner
• Resource Server
• Client
• Authorization Server

Resource Owner

In OAuth terms, resource owner is the data of the owner which the third party wants to access. In our case, you as a user are the resource owner and the third-party application wants to check if you are registered with google and want some of your data.

Resource Server

The resource server is the one who is hosting your protected data, in our case Google is the one who has kept the data. Typically, modern web applications keep the resource server and authorization server in one application.

Client

The client is the webserver or javascript application that wants to access your data from another server. In our case, the client is the site something.com.

Authorization Server

The server manages everything related to security e.g granting access token to the client application and verifying the token. In our case, google's authorization server will grant access token after successful authentication and your consent.

There are certain types of grant types(grant types are nothing but a way of authenticating the client on behalf of the user) available in Oauth and we will discuss about the authorization flow as well as all grant types.

Abstract Protocol Flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

The above flow that we see is the top-level authentication/authorization process representation. Oauth term this flow as abstract protocol flow.

OAuth Authorization Grants

An authorization grant is a type of credentials that represents resource owner authorization for accessing a protected resource. In our case when you go and log in on the google page and authorize the permissions that the application is requesting for then the authorization server returns a kind of code which then the client application sends the authorization server to get an access token as we've seen in abstract protocol flow.

OAuth defines 4 types of authorization grants.

1. Authorization Code
2. Implicit
3. Resource Owner's password credentials.
4. Client Credentials

OAuth Authorization Code Grant

In this type of grant, the client first requests the authorization code from the authorization server and then uses that authorization code to exchange it for an access token. The flow works this way, you visit a third-party site and it redirects you to the authorization server's login page, and you log in there, the authorization server redirects you back to the site issuing the authorization code. The client application then uses the authorization code to get the access token for accessing your protected resources on the resource server.

Authorization Code Grant Flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Implicit Grant

Implicit grant types are mostly used for javascript applications because there is no intermediate operation like issues authorization code. Instead of issues an authorization code first when the client redirects you to the authorization server's login page and the moment you authorize the client to access your request, the authorization server grants the client access token. Unless you are left with no options, please prefer using the authorization code grant because it is a more secure way to authenticate the third party sites. 

Implicit Grant flow

     +--------+                               +---------------+
     |        |<-(B)-- Authorization Grant ---|   Resource    |
     |        |                               |     Owner     |
     |        |                               |               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(A)- Authorization Request ->| Authorization |
     | Client |                               |     Server    |
     |        |<-(c)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(D)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(E)--- Protected Resource ---|               |
     +--------+                               +---------------+

Resource Owner's Password Credentials Grant

In this type of authorization grant, the access token can be directly obtained by using the resource owner's credentials and this type of grant should be only used when there is a high degree of trust between the client and resource server. i.e the client application is a part of the operating system or highly privileged application and when there are no other types of grants are available.

Password Credentials Grant Flow

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

Client Credentials Grant

In this type of grant, the client application can request the access token by only using its client credentials. When the client is requesting access to the protected resource under its control, or those of another resource owner have been previously arranged with another resource owner. You should be using this type of grant type only with clients capable of granting the guarantee of your data security.

Client Credentials Flow 

     +---------+                                  +---------------+
     |         |                                  |               |
     |         |>--(A)- Client Authentication --->| Authorization |
     | Client  |                                  |     Server    |
     |         |<--(B)---- Access Token ---------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

Thank you guys for reading my article. I will be sharing more articles about implementing your own authorization server, resource server as well as client-server so that we can see this in practical.