OAuth 2.0 Introduction?

OAuth is an open authorization protocol, which will allows accessing of the resources from the resource owner by enabling the client applications on HTTP services such as Facebook, GitHub, etc. It allows sharing of resources stored on one site to another site without using their credentials. It uses username and password tokens instead.
OAuth 2.0 is developed by the IETF OAuth Working Group, published in October 2012.

Usage

  • we can use OAuth 2.0 to read user data from another application.
  • It provides the authorization workflow for web, desktop applications, and mobile devices.
  • It is a server side web app that uses authorization server and does not interact with user credentials.

Features

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

Advantages 

  • OAuth 2.0 is a very flexible protocol that relies on SSL (Secure Sockets Layer that ensures data between the web server and browsers remain private) to save user access token.
  • OAuth 2.0 relies on SSL which is used to ensure cryptography industry protocols and are being used to keep the data safe.
  • It allows limited access to the user's data and allows accessing when authorization tokens expire.
  • It has ability to share data for users without having to release personal information.
  • It is easier to implement and provides stronger authentication.

Disadvantages

  • If you are adding more extension at the ends in the specification, it will produce a wide range of non-interoperable implementations, which means you have to write separate pieces of code for Facebook, Google, etc.
  • If your favorite sites are connected to the central hub and the central account is hacked, then it will lead to serious effects across several sites instead of just one.

Architecture

In this chapter, we will discuss the architectural style of OAuth 2.0.
OAuth 2.0 Architecture
Step 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 is 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 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 them 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.
OAuth 2.0 has various concepts, which are briefly explained in the following table.
Sr.No.Concept & Description
1Terminology
OAuth provides some additional terms to understand the concepts of authorization.
2Web Server
Web server delivers the web pages and uses HTTP to serve the files that forms the web pages to the users.
3User-Agent
The user agent application is used by client applications in the user's device, which acts as the scripting language instance.
4Native Application
Native application can be used as an instance of desktop or mobile phone application, which uses the resource owner password credentials.

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 client requests an access token only with the help of client credentials.
  • The client credentials authorization flow is used to acquire access token to authorize API requests.
  • Using client credentials authorization, access token which is acquired, only grants permission for your client application to search and get catalog documents.
The following figure explains the Client Credentials Flow.
Client Credentials Flow
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 access token if it's valid and authorized.
The following table lists the concepts of Client Credentials.
Sr.No.Concept & Description
1Obtaining End-User Authorization
The authorization end point is typically URI on the authorization server in which the resource owner logs in and permits to access the data to the client application.
2Authorization Response
The authorization response can be used to get the access token for accessing the owner resources in the system using the authorization code.
3Error Response and Codes
The authorization server responds with a HTTP 400 or 401 (bad request) status codes, if an error occurs during authorization.

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 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
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.
Following table lists the concepts of Client Credentials.
Sr.No.Concept & Description
1Authorization Code
The authorization code allows accessing the authorization request and grants access to the client application to fetch the owner resources.
2Resource Owner Password Credentials
The resource owner password credentials include only one request and one response, and is useful where the resource owner has a good relationship with the client.
3Assertion
Assertion is a package of information that makes the sharing of identity and security information across various security domains possible.
4Refresh Token
The refresh tokens are used to acquire a new access tokens, which carries the information necessary to get a new access token.
5Access Token Response
Access token is a type of token that is assigned by the authorization server.
6Access Token Error Response Codes
If the token access request, which is issued by the authorization server is invalid or unauthorized, then the authorization server returns an error response.

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 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.
The following table shows the concepts of accessing protected resource.
Sr.No.Concept & Description
1Authenticated Requests
It is used to get the authorization code token for accessing the owner resources in the system.
2The WWW-Authenticate Response Header Field
The resource server includes the "WWW-Authenticate" response header field, if the protected resource request contains an invalid access token.


Comments

Popular posts from this blog

Email Sending through O365 using OAuth Protocol

IISRESET vs App Pool Recycling ?

Deploy .Net6.0 Web api with docker