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.
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 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.
During authorisation, there are different grant types that can be issued for different use cases:
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.
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
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.