oauth 2.0

OAuth 2.0

OAuth 2.0 is a widely used authorization framework that allows an application (client) to obtain limited access to protected resources on behalf of a user or the application itself.

Edit on GitHub

What is OAuth 2.0?

OAuth 2.0 is the de facto standard for authorization and is widely used across the web. It allows an application to securely obtain limited access to protected resources on another application, such as a user’s profile or data, without exposing credentials like passwords.

Let’s see a real-world example to understand better. You have a web application MyApp that wants to access the user’s Google Drive. Instead of asking the user to share their Google Drive credentials, MyApp can use OAuth 2.0 to request access to Google Drive on behalf of the user. Here’s a simplified flow:

In this flow, MyApp never sees the user’s Google Drive credentials. Instead, it receives an Access token from Google that allows it to access Google Drive on behalf of the user.

Key components of OAuth 2.0

For the above example, MyApp is the Client , Google is both the Authorization server and the Resource server , and the user is the Resource owner . The flow involves all the key components of OAuth 2.0:

Client: The application that wants to access the protected resources. “Client” and “application” are often used interchangeably.
Resource owner: The user who owns the protected resources. The resource owner can grant (authorize) or deny access to the client.
Authorization server: The server that performs authorization (usually with authentication) and issues access tokens to the client.
Resource server: The server that hosts the protected resources. It verifies the access token and serves the protected resources to the client.

OAuth 2.0 grants (flows)

Grant builds the foundation of OAuth 2.0 and defines how the client can obtain an access token from the authorization server. The basic OAuth 2.0 specification defines four grants:

Without going into the details of each grant, we can expect these grants into two categories:

Authorization grants: Used when the client needs to access resources on behalf of a user, i.e., user authorization is required.
Client credentials grant: Used when the client needs to access resources on its own behalf. This grant is suitable for Machine-to-machine communication.

Authorization grants

Regardless of the grant type, authorization grants have the following common steps:

The client initiates an Authorization request to the authorization server.
The authorization server authenticates the user (resource owner) and asks for permission to access the resources.
The user grants permission to the client.
The authorization server issues an access token to the client.
The client uses the access token to access the protected resources on the Resource server .

Note that the exact steps and parameters may vary depending on the grant type. For example, the authorization code grant involves more steps like code generation and exchange.

Client credentials grant

The client credentials grant is much simpler and doesn’t involve user authorization. Here’s a simplified flow:

The client sends a Token request to the authorization server.
The authorization server authenticates the client and issues an access token.
The client uses the access token to access the protected resources on the Resource server .

For in-depth discussions on OAuth 2.0 grants, see OAuth 2.0 grant and the specific grant articles.

Access control with OAuth 2.0

OAuth 2.0 defines the Scope parameter to specify the permissions the client is requesting. The authorization server may fully or partially ignore the requested scopes and grant access based on its own access control policies.

However, OAuth 2.0 leaves the authorization server its own discretion on how to enforce Access control . It means the authorization server can decide what resources the subject (user or client) can access and what actions they can perform on those resources.

Let’s still use the Google Drive example. MyApp may initiate an authorization request to access another user’s Google Drive by mistake. In this case, Google’s authorization server should deny the request because the user doesn’t have the necessary permissions to access another user’s Google Drive.

Another case is when MyApp receives an access token from Google that allows it to read files from the user’s Google Drive. However, MyApp tries to delete a file instead of reading it. The resource server (Google) should deny the request.

Both cases demonstrate why Access control is required when implementing OAuth 2.0. The Authorization server and the Resource server should work together to enforce access control policies and protect the resources.

Access control models

To properly handle access control, it is recommended to use the standard access control models like Role-based access control (RBAC) and Attribute-based access control (ABAC) . These models have been proven to be effective in the industry and provide the scalability for future requirements.

OAuth 2.1

OAuth 2.1 is a proposed update to the OAuth 2.0 specification that aims to improve security and usability according to the industry experience over the years. While OAuth 2.1 is not finalized yet, we can still learn about the proposed changes and understand how they may affect the current OAuth 2.0 implementations. OAuth 2.1 can be treated as a formalization of the best practices and security recommendations that have been widely adopted in the industry.

OAuth 2.0 and OpenID Connect (OIDC)

OAuth 2.0 only defines the authorization process and doesn’t cover user authentication or identity. For this reason, OpenID Connect (OIDC) was introduced as an identity layer on top of OAuth 2.0. OIDC extends OAuth 2.0 to provide user authentication and identity information in the form of ID token .

OpenID Connect extends two OAuth 2.0 grants (authorization code and implicit) to include ID tokens, and introduces a new grant called the hybrid flow that combines both.

That is to say, all your OAuth 2.0 knowledge and practices can be directly applied to OIDC; all OAuth 2.0 extensions such as Proof Key for Code Exchange (PKCE) and Resource indicator can be used in OIDC as well.