Open Authorization (OAuth 2.0)

Open Authorization (OAuth) is an open-standard framework for delegated authorization. OAuth provides the capability for applications to access the protected data or resources of a user of a third-party application, without exposing or having the need to provide login credentials of that application to the party that needs to access the data.

When an application wants to access third-party resources on behalf of the user, instead of requesting the username and password for the third-party application from the user, OAuth framework is used now to obtain an access token which grants access and permission to a predefined set of resources. Using OAuth secures the user resources, as otherwise, login credentials may have to be provided, and providing login credentials to another application gives the application the ability to perform any action as the user. For example, if the application needs to access only the email contacts, but users have to provide the login credentials for the application to access the contacts, the application will have the capability to perform actions like sending emails to people pretending to be the real user, and perform actions for which the user may not have originally intended to give permission.

How OAuth Works

The picture below illustrates how OAuth works using Authorization Code Grant Type (other grant types also have a similar flow with slight differences):

Roles

• Client - This is the resource requester; the application which requests resources on the user's behalf.
• Authorization Server - This is the third-party application that issues the access tokens for accessing its resources.
• Resource Server - This also belongs to the third-party application which contains the resources that needs to be requested. 
• Resource Owner - This is the user; the owner of the protected resources. 

Protocol Endpoints

Both the Authorization Endpoint and the Token Endpoint are located in the Authorization Server while the Redirection Endpoint (Redirect URI in the diagram above) is located at the Client application.

• Authorization Endpoint - This is used to get the user's approval/authorization to issue an access token to access the protected resources.
• Redirection Endpoint - This is the endpoint to which the Authorization Server sends responses to in the client application, after receiving and processing the requests made on the Authorization Endpoint and the Token Endpoint.
• Token Endpoint - This endpoint issues the access tokens.

The following are some of the important points that must be noted regarding OAuth:

• Both the Authorization Code and the Access Token have a validity period which means that it will expire after a certain time period decided by the Authorization Server.

• Authorization Code can be seen in the browser request, but others like the Access Token cannot be seen as the communication which takes place after user access consent is server-to-server communication.

• The Client application must be registered with the third-party application which contains the resources, so that it can identify the client who requests the resources. Upon registering the application, you will receive the Client Id (Consumer Key/Client Key/App Id) which is the username of the application, and the Client Secret (Consumer Secret/App Secret) which is the password of the application requesting the information. 

• Client Id of the registered application must be sent to the Authorization Server when requesting both Authorization and Access Token.

• Scope refers to the permissions that needs to be requested.

• Multiple permissions can be requested at the same time using Scope.

• State is a random string which is used to prevent CSRF, and is therefore recommended. It is sent to the Authorization Server, and the server sends it back to the client in response. 

• Resource Server defines which resources can be accessed and using which scopes.

• Client Secret must be sent to the Authorization Server when requesting an Access Token as the server has to validate the requester. The initial request does not need to have the Client Secret sent to the server.

• The user has to give the consent only once.

Grant Types

There are several ways in which Access Tokens can be obtained, and these mechanisms are called Grant Types.

1. Authorization Code Grant Type - This is used to develop Server-side Web Applications.
2. Implicit Grant Type - This is used in implementing Client-side Applications like Single-page JavaScript applications. It has no Token Endpoint as initial response itself returns a Token.
3. Resource Owner Password Credentials - This is used in Trusted Apps like Facebook Mobile App where username and password is requested, and is possible to provide the login credentials without any worries. It has only the Token Endpoint, and does not have an Authorization Endpoint.
4. Client Credentials - This is used in Server-to-server communication, and it has no user involved. There are times when although no user is involved, information must be exposed securely to outsiders or other applications. For instance, this can be used when retrieving data like Weather data or Traffic data from an API. It has only the Token Endpoint, and does not have an Authorization Endpoint.

Some Use Cases

• Logging on to websites using other social websites like Facebook, LinkedIn, Twitter, etc. 
• Automating the uploading of some files to Google Drive.
• Retrieve data from Facebook and display it or carry out some processing. For example, this is done by the fun applications that access information and predicts things like "What your profile picture reveals about you?" or "When will you die?"
• Accessing Gmail contacts.
• Access Photos stored on another site.
• Updating Gaming Scores and storing them on another site.

One of the advantages of using Social Websites to login to other websites is that you do not need to create multiple accounts, but at the same time, one of the disadvantages is that it can become a single point of failure because if the credentials to the social website are leaked, then others can have access to all the other websites you logged into using the social login.

While OAuth protects the users' resources, one of the disadvantages of OAuth is that whoever bearing the Access Token can access the data, which means if an attacker gets or steals this Access Token, they can get the permission-given data until the Access Token expires.