Workflow of OAuth 2.0

OAuth2.0 is an Open industry-standard authorization protocol that allows a third party to gain limited access to another HTTP service, such as Google, Facebook, and GitHub, on behalf of a user, once the user grants permission to access their credentials. 

Most websites require you to complete a registration process before you can access their content. It is likely that you have come across some buttons for logging in with Google, Facebook, or another service.

GeeksforGeeks Registration Page 

Clicking those buttons will get you access to these third-party services without entering any credentials. I’m sure you’re wondering how this happens. OAuth brings this to light.

Let’s have a quick refresher on Authentication and Authorization before we dive into OAuth. Authorization refers to the process by which an administrator grants access to authenticated users, whereas authentication verifies that the user is who they claim to be.

Consider the GeeksforGeeks website as an example.

As a reader, you can read blogs without authenticating, but to add comments, you must register. Once you’ve signed up, you can access the free courses, improve articles and contribute. As a contributor, you have the right to edit your articles.

Let us now discuss OAuth.

OAuth is an open-standard authorization framework that enables third-party applications to gain limited access to user’s data.

Essentially, OAuth is about delegated access.

Delegation is a process in which an owner authorizes a service provider to perform certain tasks on the owner’s behalf. Here the task is to provide limited access to another party.

Let’s take two real-life examples;

House owners often approach real estate agents to sell their house. The house owner authorizes the real estate agent by giving him/her the key. Upon the owner’s consent, the agents show the buyers the property. The buyer is welcome to view the property, but they are not permitted to occupy it. In this scenario, the buyer has limited access, and the access is limited by the real estate agent who is acting on the owner’s behalf.

A  classic example of valet parking is often retold to understand this concept. In this case, the car owner has access to both the car and the valet. To have his car parked for him, the car owner gives the valet key to the attendant. The valet key starts the car and opens the driver’s side door but prevents the valet from accessing valuables in the trunk or glove box.

Thus, the Valet key has delegated the task of limiting the access of the valet.

What is the point of OAuth?

OAuth allows granular access levels. Rather than entrusting our entire protected data to a third party, we would prefer to share just the necessary data with them. Thus, we need a trusted intermediary that would grant limited access(known as scope) to the editor without revealing the user’s credentials once the user has granted permission.(known as consent).

Here’s an example of an application for editing photos.

You go to a photo editing app to resize an image. They ask you to upload the image you want to edit from your Google Drive account. The third party only needs access to the single photo you need to edit. Oauth will ensure that the photo editor gets just that.

Let’s take another example, you would like to share your edited picture with your friend, but they must have the same editing software. The editing software cannot request your Google account credentials; instead, it redirects you to your account. If you choose to invite your friend through that app, the app will request access to your Google address book to send the invitation.

• Read/write only -A third party can only read your data, not modify it. In some instances, it can also request content modifications on your account. For example, you can cross-post a picture from your Instagram account to your Facebook account.
• Revoke Access –You can deauthorize Instagram’s access to your Facebook wall so it can no longer post on your wall.

Before we get into how OAuth works, we’ll discuss the central components of OAuth for more clarity.

The elements of OAuth are listed below:

1. Actors
2. Scopes and Consent
3. Tokens
4. Flows

Actors:

 OAuth Interactions have the following Actors:

OAuth2.0 Actors 

• Resources are protected data that require OAuth to access them.
• Resource Owner: Owns the data in the resource server. An entity capable of granting access to protected data. For example, a user Google Drive account.
• Resource Server: The API which stores the data. For example, Google Photos or Google Drive.
• Client: It is a third-party application that wants to access your data, for example, a photo editor application.

There seems to be an interaction between two services for accessing resources, but the issue is who is responsible for the security. The resource server, in this case, Google Drive, is responsible for ensuring the required authentication.

OAuth is coupled with the Resource Server. Google implements OAuth to validate the authorization of whoever accesses the resource.

• Authorization Server: OAuth’s main engine that creates access tokens.

Scope and Consent:

The scopes define the specific actions that apps can perform on behalf of the user. They are the bundles of permissions asked for by the client when requesting a token.

For example, we can share our LinkedIn posts on Twitter via LinkedIn itself. Given that it has write-only access, it cannot access other pieces of information, such as our conversations.

On the Consent screen, a user learns who is attempting to access their data and what kind of data they want to access, and the user must express their consent to allow third-party access to the requested data. You grant access to your IDE, such as CodingSandbox, when you link your GitHub account to it or import an existing repository. The Github account you are using will send you an email confirming this.

GitHub confirmation Email

Now let’s talk about access and refresh tokens. 

What is a token?

A token is a piece of data containing just enough information to be able to verify a user’s identity or authorize them to perform a certain action.

We can comprehend access tokens and refresh tokens by using the analogy of movie theatres. Suppose you (resource owner) wanted to watch the latest Marvel movie (Shang Chi and the Legends of the Ten Rings), you’d go to the ticket vendor (auth server), choose the movie, and buy the ticket(token) for that movie (scope). Ticket validity now pertains only to a certain time frame and to a specific show. After the security guy checks your ticket, he lets you into the theatre (resource server) and directs you to your assigned seat.

If you give your ticket to a friend, they can use it to watch the movie. An OAuth access token works the same way. Anyone who has the access token can use it to make API requests. Therefore, they’re called “Bearer Tokens”. You will not find your personal information on the ticket. Similarly, OAuth access tokens can be created without actually including information about the user to whom they were issued. Like a movie ticket, an OAuth access token is valid for a certain period and then expires. Security personnel usually ask for ID proof to verify your age, especially for A-rated movies. Bookings made online will be authenticated by the app before tickets are provided to you.

So, Access tokens are credentials used to access protected resources. Each token represents the scope and duration of access granted by the resource owner and enforced by the authorization server. The format, structure, and method of utilizing access tokens can be different depending on the resource server’s security needs.

A decoded access token, that follows a JWT format. 

{ "iss": "https://YOUR_DOMAIN/",
 "sub": "auth0|123456",
  "aud": [   "my-api-identifier",   "https://YOUR_DOMAIN/userinfo" ],
  "azp": "YOUR_CLIENT_ID", "exp": 1474178924, "iat": 1474173924,
  "scope": "openid profile email address phone read:meetings" }    

 Now that your showtime has expired and you want to watch another movie, you need to buy a new ticket. Upon your last purchase, you received a Gift card that is valid for three months. You can use this card to purchase a new ticket. In this scenario, the gift card is analogous to Refresh Tokens. A Refresh token is a string issued to the client by the authorization server and is used to obtain a new access token when the current access token becomes invalid.

They do not refresh an existing access token, they simply request a new one. The expiration time for refresh tokens tends to be much longer than for access tokens. In our case, the gift card is valid for three months, while the ticket is valid for two hours. Unlike the original access token, it contains less information.

Let us now look at how OAuth works when uploading a picture to a photo editor to understand the workflow.

1. The resource owner or user wishes to resize the image, so he goes to the editor (client), tells the client that the image is in Google Drive (resource owner), asking the client to bring it for editing.
2. The client sends a request to the authorization server to access the image. The server asks the user to grant permissions for the same.
3. Once the user allows third-party access and logs into the website using Google, the authorization server sends a short-lived authorization code to the client.
4. Clients exchange auth codes for access tokens, which define the scope and duration of user access.
5. The Authorization Server validates the access token, and the editor fetches the image that the user wants to edit from their Google Drive account.

An overview of the OAuth workflow

1. Authorization Code Flow:

Authorization code flow 

1. The client requests authorization by directing the resource owner to the authorization server.
2. The authorization server authenticates the resource owner and informs the user about the client and the data requested by the client. Clients cannot access user credentials since authentication is performed by the authentication server.
3. Once the user grants permission to access the protected data, the authorization server redirects the user to the client with the temporary authorization code.
4. The client requests an access token in exchange for the authorization code.
5.  The authorization server authenticates the client, verifies the code, and will issue an access token to the client.
6. Now the client can access protected resources by presenting the access token to the resource server.
7. If the access token is valid, the resource server returns the requested resources to the client.

2.  Implicit Flow :

Implicit Grant flow is an authorization flow for browser-based apps. Implicit Grant Type was designed for single-page JavaScript applications for getting access tokens without an intermediate code exchange step. Single-page applications are those in which the page does not reload and the required contents are dynamically loaded. Take Facebook or Instagram, for instance. Instagram doesn’t require you to reload your application to see the comments on your post. Updates occur without reloading the page. Implicit grant flow is thus applicable in such applications.

The implicit flow issues an access token directly to the client instead of issuing an authorization code.

The Implicit Grant:

• Constructs a link and the redirection of the user’s browser to that URL.

https://example-app.com/redirect  #access_token=g0ZGZmPj4nOWIlTTk3Pw1Tk4ZTKyZGI3  &token_type=Bearer  &expires_in=400  &state=xcoVv98y3kd55vuzwwe3kcq    

• If the user accepts the request, the authorization server will return the browser to the redirect URL supplied by the Client Application with a token and state appended to the fragment part of the URL. (A state is a string of unique and non-predictable characters.)
• To prevent cross-site forging attacks, the application should test the incoming state value against the value that was originally set, once a redirect is initiated. (We are a target of an attack if we receive a response with a state that does not match).
• The redirection URI includes the access token, which is sent to the client. Clients now have access to the resources granted by resource owners.

This flow is deprecated due to the lack of client authentication. A malicious application can pretend to be the client if it obtains the client credentials, which are visible if one inspects the source code of the page, and this leaves the owner vulnerable to phishing attacks.

There is no secure backchannel like an intermediate authorization code – all communication is carried out via browser redirects in implicit grant processing. To mitigate the risk of the access token being exposed to potential attacks, most servers issue short-lived access tokens.

3.  Resource owner password credentials flow:

In this flow, the owner’s credentials, such as username and password, are exchanged for an access token. The user gives the app their credentials directly, and the app then utilizes those credentials to get an access token from a service.

1. Client applications ask the user for credentials.
2. The client sends a request to the authorization server to obtain the access token.
3. The authorization server authenticates the client, determines if it is authorized to make this request, and verifies the user’s credentials. It returns an access token if everything is verified successfully.
4. The OAuth client makes an API call to the resource server using the access token to access the protected data.
5. The resource server grants access.

The Microsoft identity platform, for example, supports the resource owner password credentials flow, which enables applications to sign in users by directly using their credentials.

It is appropriate for resource owners with a trusted relationship with their clients. It is not recommended for third-party applications that are not officially released by the API provider.

Why Resource Owner Password Credentials Grant Type is not recommended?

1. Impersonation: Someone may pose as the user to request the resource, so there is no way to verify that the owner made the request.
2. Phishing Attacks – A random client application asks the user for credentials. Instead of redirecting you to your Google account when an application requests your Google username and password.
3. The user’s credentials could be leaked maliciously to an attacker.
4. A client application can request any scope it desires from the authorization server. Despite controlled scopes, a client application may be able to access user resources without the user’s permission.

For example, in 2017, a fake Google Docs application was used to fool users into thinking it was a legitimate product offered by Google. The attackers used this app to access users’ email accounts by abusing the OAuth token.

4. Client Credentials Flow:

The Client credentials flow permits a client service to use its own credentials, instead of impersonating a user to access the protected data. In this case, authorization scope is limited to client-controlled protected resources.

1. The client application makes an authorization request to the Authorization Server using its client credentials.
2. If the credentials are accurate, the server responds with an access token.
3. The app uses the access token to make requests to the resource server.
4. The resource server validates the token before responding to the request.

OAuth 2.0 vs OAuth 1. 0

The versions of OAuth are not compatible, as OAuth 2.0 is a complete overhaul of OAuth 1.0. Implementing OAuth 2.0 is easier and faster. OAuth 1.0 had complicated cryptographic requirements, supported only three flows, and was not scalable.

Now that you know what happens behind the scenes when you forget your Facebook password, and it verifies you through your Google account and allows you to change it, or whenever any other app redirects you to your Google account, you will have a better understanding of how it works.