Deep Dive Into OAuth2.0 and JWT (Part 2 OAuth2.0)

In the previous article, we introduced Authentication and Authorization. In this article, let us have a look at one of the most commonly used implementation, i.e. OAuth2.0.

Introduction

In the traditional client-server authentication model, the client requests protected resources on the server by authenticating with the server using the resource owner's credentials. To provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This sharing of credential can create several problems and limitations, some of which are listed below.

• Third-party applications are required to 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 without any ability to restrict duration or access to a limited subset of resources.
• Resource owners cannot revoke access to an individual third party without revoking access to all third parties and must do so by changing the third party's password.

OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. So.

OAuth is an authorization protocol, which allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.

OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials.Let us try to understand with an example.

Do you know that there are cars with valet keys? If you don’t already know, there are cars (yes, those luxury ones!) that come with a special type of key you give the parking attendant. Unlike your regular key, this key will not allow the car to drive more than a mile or two.

Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.

Similarly, in OAuth instead of valet keys we have Access Tokens allowing different level of access to resources.

OAuth2.0: Terminology

Roles: The OAuth2.0 specification defines four roles

1. Resource Owner: An entity capable of granting access to protected resource. When this entity is a person, it is referred as end-user.
2. Resource Server: The server hosting the protected resource, capable of accepting and responding to the request to protected resource using access tokens.
3. Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
4. Authorization Server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Tokens: There are two types of tokens.

1. Access Token: An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and duration's of access, granted by the resource owner, and enforced by the resource server and authorization server.
   
   The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature).
2. Refresh Token: Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).
   
   Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token.

Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.

Authorization Grant: An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. OAuth2.0 specification defines four grant types

1. Authorization Code: 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, which in turn directs the resource owner back to the client with the authorization code.
2. Implicit Grant: Instead of issuing the client an authorization code, the client is issued an access token directly.
3. Resource owner password credentials (ROPC): The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. ROPC should only be used when there is a high level of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
4. Client Credentials: The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.

It is very important to understand these terminologies while working with OAuth2.0. So, let us try to understand these with an example.

Think of metro rail transportation system. The onboarding flow typically goes as follows: A commuter requests tickets/token from a vending machine or ticket vendor. The ticket vendor/machine grants token/ticket valid for a limited duration and/or number of stations. Then, the commuter presents this token to access gates; if the token is valid, the access gates allow the entry, and the commuter can board the train.

The scenario above can be mapped to the following roles in OAuth2.0.

Commuter (Client) wants to use metro (Protected Resource), so s/he asks the ticket vendor for tickets for metro (Resource Server). The ticket vendor (Authorization Server) grants access in terms of ticker/tokens (Tokens) on behalf of the metro authorities (Resource Owner).

OAuth2.0: Control Flow:

An OAuth2.0 flow can be represented with the following flow diagram.

OAuth2.0: Use Cases

OAuth2.0 decouples authentication from authorization policy decisions. Properly designed OAuth2.0 tokens can enable both fine-grained and coarse-grained authorization. For any scenario where you want to access the resource/data stored at one place from another place (servers/applications), OAuth2.0 can be one of the best fits.

Below are some of the scenarios. We will try to understand the use cases with an example of a wearable devices, let’s say a fitness band.

• Let's assume Alice has bought a fitness band and uses the mobile app of the band provider for tracking and analyzing her progress. So what would be that flow?
• First, Alice needs to create her profile in the mobile app. Either the app could provide the profile creation form, and Alice could use that to create profile, or the app could access and pull in profile data from some other app where Alice already has data stored. Let us say FriendBook, a definitely not real social media site.
• That app will redirect to FriendBook’s login. Once Alice successfully logs in using her credentials, she will be presented with a consent page where she will allow/validate what information she wants to share and what access rights she wants to allow to be stored on FriendBook. After confirmation, the app can pull data from FriendBook using OAuth2.0 and use that.
• The wearable device will send data to app, and then, the app will sync data with the server for historical and analytical purposes.

Client Password: (Though authentication using OAuth2.0 should be avoided). Alice did not had to create a new password; instead, she used her already-created password and the FriendBook server.

Web Server: The app for the wearable band did not have to ask for login each time. Alice wants to share data to or pull data from FriendBook. The app will be able to access data with server to server authentication.

User-Agent: The app is running as an agent for the app's server, which is syncing data to and from a central server. This agent can access resources on the server (data) flawlessly, as this authorizes using OAuth2.0.

Though there can easily be a dedicated book only covering OAuth2.0, I have tried to summarize the main concepts in this article. In the next article, we will look at another token-based implementation i.e. JWT.

Please share your valuable comments, questions and feedback. Thank you for reading.

Further Reading

• Security: Defending Your Code.
• Java EE Security Essentials.
• What Is a JWT Token?