OAuth 2.0 which is a successor of OAuth 1.0 is a widely used authorization framework (sometimes referred as authorization protocol) which enables third party applications to access protected resources from resource servers on behalf of resource owners in a secured, reliable manner.

In this post, I will explain how OAuth works, what are different OAuth roles and what are different grant types available in OAuth authorization framework.

What is OAuth 2? Introduction to OAuth Framework

As stated above, OAuth 2.0 is an authorization framework for enabling resource sharing in a secured manner through a sequence of steps where resource owner permits a client application to a certain protected resource for a limited time.

If you prefer to read about OAuth authorization mechanism in text format–Continue reading below tutorial.

OAuth framework enables client applications by using delegation pattern in which certain functionalities can be delegated to an existing resource server without replicating the same feature E.g. if you are using an application which wants to access some files on a Google Drive, such access can be given through OAuth based authorization. In similar way, if you visit a website which provides you option of single sign-on, you may simply utilize your existing Facebook, Google or Twitter account through OAuth based authorization and then continue using that site without signing up with a separate account on that site.

OAuth Roles

When we talk about OAuth authorization framework, there are multiple roles associated with it which come into the picture during a series of steps that take place during authorization process.

Below are the major OAuth Roles:

• Resource Owner

Resource owner is the user who actually owns protected resources on any resource server. E.g. If you own certain files on Google Drive, you are the resource owner for those protected files. If you have an account on Twitter, Facebook or Gmail, you are the resource owner for the data that belongs to that account.

Resource owner is among the primary roles in OAuth flow as any authorization can not be granted without consent of resource owner.

• Client Application

Client application is third-party application (website, mobile-app or even a desktop app) which is registered already with an authorization server and requests access to protected resources on a resource server on behalf of a user (resource owner).

E.g. when you visit a website abc which prompts you to grant access to your profile information on Twitter; that website abc will be considered as client in this OAuth flow.

• Authorization Server

Authorization server is responsible for providing authorization grant and access tokens to the client on behalf of a resource owner.

Its important to understand that authorization server issues access tokens on behalf of a user only once user has been authenticated first.

• Resource Server

Resource server is the server that hosts the protected resource for a resource owner. Any protected resources on a resource server are accessible only to the resource owner once authenticated or to any client application which has been granted access by the resource owner by getting access token issued through authorization server.

OAuth Flow Diagram

All the OAuth roles explained above, take part in the sequence of events that take place for authorization using OAuth framework. Actual sequence of steps and low level details may vary depending on grant type, but in general, below is the high level flow for OAuth authorization framework:

OAuth Grant Types

OAuth 2.0 framework provides various grant types–each serving a specific use-case.

Below are the most common grant types associated with OAuth framework:

OAuth Grant Type: Authorization Code

Authorization Code grant type is considered as the most secure grant type. In this type of grant, Client first gets authorization code from Resource Server before requesting access token from authorization server.

In this grant type, client first accesses authorization server by redirecting the user. Following parameters are sent (query parameters) in this case to authorization server:

• response_type containing the value code
• client_id with the client identifier which is unique for a client.
• redirect_uri with the client redirect URI. This parameter is optional, but if not send the user will be redirected to a pre-registered redirect URI.
• scope a space delimited list of scopes

On Authorization server, the request is validated for all the above parameters and user is asked to login (if not already logged in) and then user is prompted to approve the request sent from the client.

Once user has approved client request, a redirection takes place back to the client application on specified redirect URI along with grant code (and an optional state value).

Now as second part of this flow, client applications sends a POST request to same authorization server in order to request an access token.

This POST request from client to the authorization server contains following important elements:

• grant_type with the hard-coded value  authorization_code

• client_id which is the client’s unique identifier
• client_secret
• redirect_uri This will be same redirect URI the user was redirect back to
• code This will be same authorization code which was sent from authorization server to call back URI in query parameters.

Once authorization server receives and validates the above POST request, he authorization server will respond with a JSON object containing the following properties:

• token_type this will usually be the word “Bearer” (to indicate a bearer token)
• expires_in with an integer value mentioning when the token will expire
• access_token the access token itself
• refresh_token a refresh token that can be used to acquire a new access token when the original expires

OAuth Grant Type: Implicit

Implicit grant type differs from authorization code grant type based on the sequence of steps as no authorization code is returned from the authorization server and access token itself is directly issued once client’s authorization request is validated and approved.

Implicit authorization grant type is used in user-agent (browser) based clients and for mobile application scenarios where client secrets can’t be safely stored with client side code easily accessible.

OAuth Grant Type: Resource Owner Password Credentials

This grant type is used only when client application is completely trusted (e.g. internal or self-hosted client) as in this case, user is asked to provide its credentials (username and password) and once user has provided its credentials, client application itself requests access token from authorization server by sending a post request containing below information:

• grant_type with the hard-coded value password
• client_id with the the client’s unique ID
• client_secret with the client’s secret
• scope with a space-delimited list of requested scope permissions.
• username with the user’s provided username
• password with the user’s provided password

Once authorization server validated above POST request, It will return access token and other related information in same way as in case of authorization code grant type.

OAuth Grant Type: Client Credentials grant

This grant type doesn’t involve a separate resource owner role as client application itself plays dual role of a client as well as resource owner and requests for an authorization to protected resource which are under the ownership of client itself.

This grant type is mostly used for server to server authorization where no external user is involved.

Ajmal Abbasi

Ajmal Hussain Abbasi is Integration Consultant By Profession with 13+ years experience in Integration domain mainly with TIBCO products. He has extensive practical knowledge of TIBCO Business Works, TIBCO Cloud, TIBCO Flogo, TIBCO Mashery, TIBCO Spotfire, EMS and TIBCO ActiveSpaces. He has worked on a number of highly critical integration projects in various sectors by using his skills in TIBCO Flogo, TIBCO API Management (Mashery), TCI, Tibco Designer, TIBCO Business Studio, Adapters, TIBCO EMS, RV, Administrator, TIBCO BE, TIBCO ActiveSpaces etc. Ajmal Abbasi has experience with MuleSoft ESB as well. Ajmal Abbasi is also experienced in the area of API Management particularly with WSO2 API management platforms. Ajmal Abbasi is also experienced in developing solutions using Core Java and J2EE Technologies. You can contact Ajmal Abbasi for Consultancy, Technical Assistance and Technical Discussions.

More Posts - Website - Facebook - LinkedIn - YouTube