The OAuth 2.0 Authorization Framework

We live in an age where interoperability in systems is essential for most business applications to offer a wide range of uninterrupted services. At the same time, preventing data and resource theft is a major concern while enabling smooth interoperability with third-party applications. The OAuth framework has been designed for this purpose.

What is OAuth Authorization? Why is it widely used?

Authentication and authorization, though used interchangeably, have entirely different meanings. Therefore, to understand the security protocols and functionalities of OAuth, it is essential to understand the difference between these two terms. Authentication is used to check whether the user exists in the system. An example is when you enter your Gmail credentials to check your mail.On the other hand, Authorization checks if the user is authorized to access a particular service. An example of this is when you enter your company email address in Google Docs to check if you have access to another user’s file.In traditional client-server authentication models, when the client wants access to restricted resources, the client usually uses the resource owner's credentials for authentication. The resource owner will have to share their credentials with the third-party client to provide resource access to third-party applications. This poses several threats and limitations.

Third-party applications store the resource owner's credentials for future use - typically a password in clear text.
Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners with no ability to restrict duration or limit access to a subset of resources.
Resource owners cannot revoke access to an individual third party without revoking access to all third-party clients and must do so by changing their passwords.
Compromise of any third-party application data results in compromising the end-user password and all the data protected by that password.

OAuth 2.0 is the industry-standard protocol for authorization meant to solve these limitations. The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party website or application access to the user's protected resources without necessarily revealing their long-term credentials or even their identity. It focuses on client-developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.OAuth introduces an additional layer of authorization that separates the role of the client from that of the resource owner. When the client requests access to resources from the application, the control of those resources remains with the resource owner. The resources are hosted by the resource server, and the client is issued a unique set of credentials. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token - a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner.The permissions granted to third-party clients are represented by access tokens or scopes in OAuth terms. The Auth0 program in the framework generates access tokens for API authorization scenarios in JSON web token (JWT) format. When an application authenticates with Auth0, it specifies the scopes it wants. If those scopes are authorized by the user, then the access token will grant these authorized scopes. The resource owner can even set the expiry of the access token. And third-party clients can generate a new token or refresh the old one after the granted access time is over. This ensures that the token will only be used by the authorized client even if it gets disclosed. This adds an additional layer of security.Oauth is used to provide limited access to the data for the client application without sharing credentials. This eliminates the concerns of authenticating users using passwords. In addition, if the client application is authorized to access restricted resources, then the application may access the authorized data of the user. And there is no possibility of an unauthorized application gaining access to those resources.Nowadays, OAuth is used widely by many applications. For instance, if you want to sign up with a new application or website, you get the option to sign up using Google, Facebook, or Twitter. Once you choose one of these options, you grant certain permissions to the application or the website. A common instance of this is when you Google or Facebook to share the user data, such as name, email ID, with the downloaded application or website. You are then identified as a registered user and allowed to enter the application. This is enabled by OAuth (Open Authorization).

The OAuth Framework

Roles used in the Oauth framework

OAuth defines four roles:

Resource Owner: The entity is capable of granting access to a protected resource. When a resource owner is a person, it is referred to as an end-user.
Resource Server: The resource server is the server hosting the protected resources. It is capable of accepting and responding to protected resource requests using access tokens.
Client: The application that makes resource requests on behalf of the resource owner and his authorization is called the client. The term "client" does not imply any implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
Authorization Server: This is the server that issues access tokens to the client after successfully authenticating the resource owner and getting authorization. There are different Authorization Grants or Flows in OAuth 2.0 as listed below in the order of highest security provided.
Authorization Code Flow
Resource Owner Credentials Flow
Client Credentials Flow
Implicit Grant Flow

Authorization Code Flow

The authorization code is obtained by using an authorization server as an intermediary between the client and the resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server, directing the resource owner back to the client with the authorization code.

Resource Owner Credentials Flow

This flow is used for first-party applications where the client is highly trusted by the server. The client directly handles user credentials in this flow. The resource owner password credentials can be used directly as authorization to obtain an access token. This flow should only be used when there is a high degree of trust between the resource owner and the client. For example, instances where the client is a part of the device operating system or a highly privileged application.

Implicit Flow

Implicit flow is a less secure mode of authorization, compared to the other grant types. It is usually used for single-page JavaScript web applications where the application may not be required to access highly sensitive information. Implicit flow is like Authorization code flow but the authorization server sends the access token directly to the client without having to send the authorization code. Implicit flow does not offer a refresh token. Once the access token expires, the user will have to generate a new one.

Client Credentials flow

Client Credentials flow is similar to the Resource Owner Credentials flow. In this flow, clients use client IDs and secrets to identify themselves and exchange them for access tokens with the authorization server. In Client credentials, it is advisable to not use flow refresh tokens as it might create security loopholes for malicious users to exploit.

Working of Authorization Code Flow

Registration with the Authorization Server

The client application must first register with the authorization server associated with the resource server. This is a one-time process. The authorization server generates a post with a client ID and a client secret key. This is used to generate authorization codes and access tokens. You can use any authorized service provider to register, i.e., Google Cloud, GitHub, etc.

Generation of Authorization Code

To generate an access token, you must have an authorization code.The client will generate a request with the client details, scope, and response URL through which the authorization server will send the authorization code. A post-call is then made to the authorization server, which can ask the owner where she/he authorizes the application to share the data. Once the owner authenticates and authorizes the resource provider, then it provides an authorization code to the client application using which token is generated.

Sample Request

https://accounts.google.com/o/oauth2/v2/auth?

scope=SCOPE&
response_type=code&
redirect_uri=REDIRECT_URI&
client_id=CLIENT_ID
The above sample is a request for a Google authorization server.

Scope: This is to limit the access of the request such as read-only, write-only, read/write both.
Response_type: This is a mandatory field and should be set to code.
Redirect_uri: Post authorization, the request should be redirected to this Uri.
Client_id: This is a mandatory field that is given by the authorization server during registration.

Response

http://localhost:8080/login/oauth2/code/google?

code=abcd1234&
scope=SCOPE
Getting access token and refresh tokenAn access token is granted to access specific data. For example, if a token is granted to access an employee’s data, it might not grant other accesses such as Accounts data. The token can be used multiple times to access the employee’s data until the token lifetime is over. Access tokens are associated for a lifetime, and a refresh token can generate a new Access token.

Request

code= abcd1234&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
redirect_uri= REDIRECT_URI&
grant_type=authorization_code

Code: Authorization code received from the above-mentioned process.
Client id: This is a mandatory field given by the authorization server during registration.
Client_secret: This is the mandatory field given by the authorization server during registration.
Redirect_uri: Post authorization, the request should be redirected to this URL.
Grant_type: “authorization_code”.

Response:

{
"access_token": "qhdidh124",
"expires_in": 3599,
"refresh_token": "jfoedf4548",
"scope": SCOPE",
"token_type": "Bearer"
}

Request
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
grant_type= refresh_token&
refresh_token = “jfoedf4548”

IdeasITAre you looking to build a great product or service? Do you foresee technical challenges? If you answered yes to the above questions, then you must talk to us. We are a world-class custom .NET development company. We take up projects that are in our area of expertise. We know what we are good at and more importantly what we are not. We carefully choose projects where we strongly believe that we can add value. And not just in engineering but also in terms of how well we understand the domain. Book a free consultation with us today. Let’s work together.