How OAuth 2.0 Works

If you have ever used Google sign-in, Facebook sign-in or Github sign-in, you have used a small part of OAuth 2.0. But how does it really work?

Photo by Micah Williams on Unsplash

OAuth is a framework to allow third parties to access your account without using your credentials i.e, keeping your username and password secret.

Roles

OAuth 2 defines four roles. These roles interact with each other during an authorization flow.

Resource Owner

It is the user who owns the account. The resource owner authorizes a client to access their account on a resource server. The client’s access to the resource (i.e, user account) is limited to the “scope” of the authorization granted (e.g. read-only or write).

Resource Server

The resource server hosts the user accounts. For Google Sign-in Google is the resource server.

Authorization Server

The authorization server verifies the identity of the user then issues access tokens to the client. The conformation page shown during a Google sign-in flow is shown by the Authorization serve

Client

The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

The Flow

1. The client requests authorization to access the resources from the resource owner (user).
2. If the user authorizes the request, the client receives an authorization grant
3. The client requests an access token from the authorization server by presenting its own credentials — client id and client secret, and the authorization grant.
4. If the application identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the application.
5. The client requests the resources from the resource server and presents the access token for authentication
6. If the access token is valid, the resource server serves the resource to the client.

Access Tokens and Refresh Tokens

Access tokens granted by the authorization server are usually short-lived. While granting the access token, in certain flows, the authorization server also issues a long lived refresh token, which can be exchanged for a new access token for another session.

Client Authentication

Before a client can request an OAuth authorization code, it has to be registered with the service provider and obtain a set of credentials for identification — client id and client secret. While registering a service provider requires at least the following:

1. Application name
2. Callback URI

The Callback URI is where the service will redirect the user after they authorize (or deny) your application, and therefore the part of the client that will handle authorization codes or access tokens.

Grants

The authorization grant type depends on the method used by the application to request authorization, and the grant types supported by the service provider.

OAuth 2 defines four grant types, each of which is useful in different cases:

• Authorization Code: used with server-side applications
• Implicit: used with Mobile or Web Apps that run on the user’s device
• Password: used with trusted applications, such as those owned by the service itself
• Client Credentials: used with clients for service account like functionality

Authorization Code

This is the most common implementation of OAuth 2.0. It is well suited for server-side applications, where client secret confidentiality can be maintained.

This flow relies on redirection which requires that the application must be capable of interacting with the user-agent (i.e. the user’s web browser) and receiving API authorization codes through the user-agent.

How it works

1. Client application redirects to the authorization server with the requested grant type as “authorization_code”, scope, client id and redirect URL as URL parameters.
2. The authorization server authenticates the user and displays a UI to confirm (or deny) the authorization.
3. On confirmation, the authorization server redirects back to the client application with a short-lived authorization code (or error in case of deny).
4. The client passes the authorization code to it’s back-end which then exchanges the code for an access token and refresh token.
5. The client uses the access token to request resources from the resource server.

Implicit

Implicit grant type is used for mobile apps and web applications, where client secret confidentiality is not guaranteed. It is also redirection-based but the access token is directly given to the user-agent to forward to the application.

This flow relies on the redirect URI that was registered with the service for authentication and does not support refresh tokens.

How it works

1. Client application redirects to the authorization server with the requested grant type as “implicit”, scope, client id and redirect URL as URL parameters.
2. The authorization server authenticates the user and displays a UI to confirm (or deny) the authorization.
3. On confirmation, the authorization server redirects back to the client application with a short-lived access token (or error in case of deny) as an URI parameter. The application extracts this token from the URI.
4. The client uses the access token to request resources from the resource server.

Password

This is the simplest OAuth 2.0 flow. This flow is only used in trusted applications such as an application owned by the service itself. In this grant type, the user provides their credentials (username and password) directly to the application, which uses the credentials to obtain an access token from the service.

How it works

1. Client application requests an access token from the authorization server with grant type as “password”, username, password and the client id.
2. The server responds with an access token.
3. The client uses the access token to request resources from the resource server.

Client credentials

The client credentials grant type provides an application a way to access its own service account.

How it works

1. Client application requests an access token from the authorization server with grant type as “client credentials”, client id and client secret.
2. The server responds with an access token.
3. The client uses the access token to request resources from the resource server.

Using Access Tokens

Access tokens are used to access protected resources from the Resource server. The most typical usage is to provide the access token with the “Authorization” HTTP header as a “Bearer” token.

http -v GET https://api.example.com/v1/example Authorization:Bearer\ token
GET /v2/ HTTP/1.1
Authorization: Bearer token
Host: api.example.com

If you wish to learn more about OAuth 2.0, the specification is described in the RFC 6749. Being ubiquitous, every major language and framework has mature support for OAuth baked it. Hope you have a good understanding about OAuth and where to use its various flows.