OAUTH 2.0

Prior to the development of OAuth, third party applications were granted access to a service or account by giving it your password. There were many obvious fears and problems when authorisation was done this way as the application logs in to the service as the user and stores the password. This also gave the application total access to account of the user which included being able to change the user’s password and this control was could only be revoked when the user changed their password.

These obvious problems led to the need for a neater way of handling authorisation and the solution developed to handle this issue was called the OAuth framework. OAuth 2.0 works on the same principle as the OAuth 1.0 but was aimed at clarifying and simplifying the otherwise complicated aspects of OAuth 1.0. This post covers the functioning of OAuth and how it has been able to provide a more secure authorisation than giving out passwords.

What is OAuth?

To put simply, it is an open authorisation standard for enabling clients gain access to protected server resources on behalf of the owner of a resource. With OAuth, users are now able to authorise third party applications to access their resources without disclosing their passwords and other credentials.

There are four roles that OAuth defines which are:

• The Resource owner- which is the user. This is the person who is allowing access to a part of their account resources which could be services, data etc. Before any system is able to act on behalf of the user, permission must be granted first
• The Resource server- this is the API/server that holds the information of the user that wants to be accessed by the third party application. This server is responsible for accepting and validating access tokens in other to grant a request when a user has allowed it.
• The Authorisation server- this can be the same server as the API. This is the server that the user interacts with when a request is made to access their account. The OAuth prompt is displayed from here and the user then denies or approves the request. Should the user authorise the application, the access token is then granted by this server and as such the authorisation server usually has two URLs. One where the authorisation request is sent to and the other for applications to grant the access tokens
• The Client- this is the third party application attempting to access the user’s resources or act on behalf of the user. Before the user’s account can be accessed by the client, the resource owner has to grant permission and this is done by directing the user to the authorisation server or going directly to the authorisation server without interacting with the user.
• Confidential clients do not expose the client secret and these type of clients are usually applications on a server referred to as web applications. Public clients like JavaScript are visible since the source code can be viewed./li>
• There is the Access Token which is a string that is needed when making the authenticated requests. This token is a representation of the authorisation by the user of a third party application. Tokens usually have a validity period and other information.
• In some cases, there is a Refresh Token that is used to request a new access token after the current one expires.

Authorisation with OAuth: Quick step by step Procedure

Registration

The first thing to do to begin the process is to register a new application with the service which needs information such as the application name, website, redirect URI etc. The redirect URIs have to be secure.

Client ID and Secret

Having registered successfully, a client ID and secret are given. The client secret is kept confidential and the client ID is public which is used to build URLs.

Authorisation

During authorisation, there are different grant types that can be issued for different use cases:

• Authorisation code
• Resource owner password credentials
• Client credentials
• Implicit

The figure below illustrates the flow of authorisation using the authorisation code grant type. On getting the grant which in this case is an authorisation code, the client can then exchange it for an access token which is used to access the protected resource.

• The process begins when a request access is made.
• The resource owner/user then grants or rejects this request. In practice this usually comes up as a dialog box where the user decides to grant authorisation or not.
• If the user does grant the authorisation, then the application redirects the user to the client and grants an authorisation code.
• The client then sends this authorisation code to the authorisation server which validates this authorisation code and if successful grants the access token.
• With the access token, the client is now able to access the resource server to get the information and files of the user.

Some applications let the client automatically regenerate the access token in the next request to retrieve the protected resource when it expires.

It is worth noting that in the request parameters, properties such as scope can be specified which tells how much of the resources can be accessed when permission is granted. More of this is detailed here

OAuth is very widely used and major companies such as Microsoft, Google, Facebook among others make use of it to permit users to have their information shared with third party applications. It has proven to be a more secure way to provide access to resources on behalf of the resource owner.