Open Authorization 2.0

Open Authorization, also known as OAuth is an open standard designed to allow access to resources hosted on other web apps on behalf of the user.

OAuth 1.0 was replaced by OAuth 2.0 in 2012 and is now the most commonly used standard for online authorization in the industry. OAuth 2.0 provides consented access and restricts actions of what the client app can perform on resources on behalf of the user, without ever sharing the user’s credentials.

The web is the main platform for OAuth 2.0 but this standard also provides a specification to handle authorizations for other client types such as browser-based applications, server-side web applications, native/mobile apps, etc.

OAuth 2.0 was designed primarily to act as an authorization protocol and not an authentication protocol, although it is also widely used to provide authentication. OAuth 2.0 uses access tokens to represent authorization on behalf of the end user. OAuth 2.0 doesn’t define a specific format for Access Tokens. However, in some contexts, the JSON Web Token (JWT) format is often used. This enables token issuers to include data in the token itself. Also, for security reasons, Access Tokens may have an expiration date.

In the following sections of the blog let us consider an example of a Photo Printing Application which provides the user with a photo printing service. The users can also upload their photos to this application from their Google drive.

Components of OAuth 2.0

OAuth 2.0 standard majorly comprises of 4 main components.

Resource Owner: As the name suggests, this is the person owning the resource. As per our example, the person who wants to print their photos through the Photo Printing Application is the resource owner.

Resource Server: The server on which the resource is present is referred to as a resource server, in our example Google drive.

Client: The application which is requesting authorization from the resource server on behalf of the resource owner. In our example, the Photo Printing Application.

Authorization Server: In this entire scenario, the burden of providing the correct authorization falls on the resource server. So the resource server also has an additional service that is responsible for providing the correct authorization. The resource server & Authorization server can be coupled together. This server is responsible for providing the Access Tokens to the client. The authorization server exposes two endpoints: the Authorization endpoint, which handles the interactive authentication and consent of the user, and the Token endpoint, which is involved in a machine-to-machine interaction.

OAuth 2.0 has 4 grant types/flows

Client Credentials : This type of flow is commonly used in machine-to-machine interactions typically when services running on the server need to communicate with each other.

Client Credentials

1. The application authentication with the authorization server is done using the Client ID and Client Secret.
2. The authorization server validates the Client ID & Client Secret.
3. Upon successful validation, the server sends an access token to the client.
4. The application can use this access token to call an API on its behalf of itself.
5. The API responds with the requested data.

Authorization code : This type of flow enables a client application to obtain authorized access to protected resources such as web APIs. Your app must be server-side because during this exchange, you must also pass along your application’s Client Secret, which must always be kept secure, and you will have to store it in your client.

Authorization Code

1. The resource owner makes a request to the client to access some data from the resource server(Ex: the user requests a printing app to import pics from google drive)
2. The client sends an authorization request to the authorization server.
3. The authorization server sends a request to the user to verify that they have allowed the client to access their data
4. Upon verification from the user, the authorization server sends an authorization token to the client. (Short-lived token)
5. The client then sends back the authorization token to the authorization server & asks for a second token which is an access token
6. The authorization server then sends the access token to the client
7. Now the client can directly call the resource server with an access token
8. The resource server verifies that the token is valid & then it provides the resource to the client.

Implicit Flow

The implicit flow is recommended for native applications and JavaScript applications where the access token is returned immediately without any extra authorization code exchange step.

Implicit Flow

1. The resource owner makes a request to the client to access some data from the resource server(Ex: the user requests a printing app to import pics from google drive)
2. The client sends an authorization request to the authorization server.
3. The authorization server sends a request to the user to verify that they have allowed the client to access their data
4. Upon verification from the user, the authorization server sends an access token to the client. As opposed to the previous flow where authorization was needed to get the access token.
5. The access token is sent to the client & client can access the resource using the access token.

Resource Owner Password Credential

Resource Owner Password Credential is not a highly recommended grant type but can be used in case the client is an extremely trusted resource. An example of a trusted resource can be when two microservices of the same application are communicating with each other.

Resource Owner Password Credentials

1. Microservice1 makes a call to microservice2’s authorization server & sends a special key as client id/ client secret
2. The auth server sends an access token with limited access only for intended services.
3. The microservice1 requests some data from microservice2.
4. The microservice2 validates the request and sends the data to microservice1.
5. If microservice1 requests for an API that does not have access as per the token then microservice2 sends an invalid access code.

Integration of OAuth 2.0 in your application provides various benefits as

• It is a flexible protocol which relies on SSL (Secure Sockets Layer) to ensure data between the web server and browsers remain private.
• SSL uses cryptography industry protocols to keep data safe.
• It uses tokenization to give limited access to the user’s data. For example, instead of storing credit card information on Amazon’s website, the credit card number, security code, and consumer name are each given “token” IDs. The tokens are given to the merchant, not the actual data.
• It is easy to implement and provides strong authentication. In addition to the two-factor authentication, tokens can be revoked if necessary (ie, suspicious activity).
• Uses a single sign-on.