What is OAuth 2.0?
OAuth is an open authorization protocol that allows accessing the resources of the resource owner by enabling the client applications on HTTP services such as Facebook, GitHub, etc. It allows the sharing of resources stored on one site to another site without using their credentials.
OAuth 2.0 is developed by the IETF OAuth Working Group, published in October 2012.

Why Use OAuth 2.0?
1. You can use OAuth 2.0 to read the data of a user from another application.
2. It supplies the authorization workflow for web, desktop applications, and mobile devices.
3. It is a server-side web app that uses authorization code and does not interact with user credentials.

Features
1. OAuth 2.0 is a simple protocol that allows access to the resources of the user without sharing passwords.
2. It provides user agent flows for running client applications using a scripting language, such as JavaScript. Typically, a browser is a user agent.
3. It accesses the data using tokens instead of using their credentials and stores data in an online file system of the user such as Google Docs or Dropbox accounts.

Benefits
1. OAuth 2.0 is a very flexible protocol that relies on Transport Layer Security (TLS) to save user access tokens.
2. OAuth 2.0 relies on TLS which is used to ensure cryptography industry protocols and are being used to keep the data safe.
3. It allows limited access to the user’s data and allows access when authorization tokens expire.
4. It has the ability to share data for users without having to release personal information.
5. It is easier to implement and provides stronger authentication.

ArchitectureCoditation-website-oauth-architectureStep 1: First, the user accesses resources using the client application such as Google, Facebook, Twitter, etc.
Step 2: Next, the client application will be provided with the client id and client password during registering the redirect URI (Uniform Resource Identifier).
Step 3: The user logs in using the authenticating application. The client ID and client password are unique to the client application on the authorization server.
Step 4: The authenticating server redirects the user to a redirect Uniform Resource Identifier (URI) using the authorization code.
Step 5: The user accesses the page located at redirect URI in the client application.
Step 6: The client application will be provided with the authentication code, client id, and client password, and send to the authorization server.
Step 7: The authenticating application returns an access token to the client application.
Step 8: Once the client application gets an access token, the user starts accessing the resources of the resource owner using the client application.

Roles
OAuth defines the following roles:
1. Resource Owner
2. Client Application
3. Resource Server
4. Authentication Server

The roles are illustrated in the following figure:Coditation-website-oauth-roles1. Resource Owner: Resource owner is defined as an entity having the ability to grant access to their own data hosted on the resource server. When a resource owner is a person, it is called the end-user.
2. Client Application: The client is an application making protected resource requests to perform actions on behalf of the resource owner.
3. Resource Server: The resource server is an API server that can be used to access the user’s information. It has the capability of accepting and responding to protected resource requests with the help of access tokens.
4. Authentication Server: The authentication server gets permission from the resource owner and distributes the access tokens to clients, to access protected resources hosted by the resource server.

ScenarioCoditation-website-oauth-serverOAuth flows / Grant Types
Coditation-website-oauth-flowOAuth 2.0 – Client Credentials
The client credentials can be used as an authorization grant when the client is the resource owner, or when the authorization scope is limited to protected resources under the control of the client.
The following figure depicts the Client Credentials Flow:Coditation-website-oauth-client credentials

The flow illustrated in the above figure consists of the following steps −

Step 1 − The client authenticates with the authorization server and makes a request for access token from the token endpoint.
Step 2 − The authorization server authenticates the client and provides an access token if it’s valid and authorized.

OAuth 2.0: Obtaining an Access Token
An access token is a string that identifies a user, an application, or a page. The token includes information such as when the token will expire and which app created that token.

  • First, it is necessary to acquire OAuth 2.0 client credentials from the API console.
  • Then, the access token is requested from the authorization server by the client.
  • It gets an access token from the response and sends the token to the API that you wish to access.

You must send the user to the authorization endpoint at the beginning.

Following is an example of a dummy request
https://publicapi.example.com/oauth2/authorize?client_id=your_client_id&redirect_uri=your_url &response_type=code

The following are the parameters and their descriptions.

  • client_id− It should be set to the client id of your application.
  • redirect_uri− It should be set to the URL. After the request is authorized, the user will be redirected back.
  • response_type− It can either be a code or a token. The code must be used for server-side applications, whereas the token must be used for client-side applications. In server-side applications, you can make sure that the secrets are saved safely.

OAuth 2.0: Accessing a Protected Resource
The client provides an access token to the resource server to access protected resources. The resource server must validate and verify that the access token is valid and has not expired.
There are two standard ways of sending credentials −

  • Bearer Token− The access token can only be placed in the POST request body or GET URL parameter as a fallback option in the authorization HTTP header.

They are included in the authorization header as follows −
Authorization: Bearer [token-value] For Example −
GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc…

  • MAC− A cryptographic Message Authentication Code (MAC) is computed using the elements of the request and is sent to the authorization header. Upon receiving the request, the MAC is then compared and computed by the resource owner.

Advantages and Disadvantages
Advantages:
Integration of third-party apps to any sites
Access can be granted for limited scope or duration
No need for users to give password on a third-party site

Disadvantages:
Writing an authorization server is somewhat complex
Interoperability issues
Bad implementation

Please do let us know if you liked our blog! Our other blogs can be accessed here.