OAuth 2.0

In traditional client-server-based applications, the client directly uses the user’s credentials to access protected resources. If third-party applications wanted to access the same resource, they would have to use the same credentials, and this poses significant security risks, such as compromised passwords and unrestricted access to the resource.

To overcome these issues, OAuth 2.0 was introduced to create an authorization layer that separates the client from the resource owner. It allows users to grant third-party applications access to their data without sharing credentials. 

OAuth Roles

OAuth 2.0 defines four key roles that work together to enable secure, delegated access to resources. Understanding these roles is critical in implementing the OAuth flow correctly.

1. Resource Owner: The entity that owns the resources on the Resource Server. This is usually a user.
2. Client: The client application that needs access to the resource owner’s resources.
3. Authorization Server: The server responsible for managing and issuing access tokens to the clients.
4. Resource Server: This server stores and manages the user’s data and accepts access tokens to grant access to the user’s resources.

To illustrate, consider logging into Twitter using your Google account. When you (Resource Owner) launch Twitter on your browser (Twitter web application is the Client), you choose to log in using Google (Authorization Server). You are redirected to Google’s login page, where you enter your credentials. Google verifies them and redirects you with the necessary tokens to Twitter.

Twitter then uses this token to request your profile information (like name, email address, etc) from Google (now Resource Server). Google validates the token and returns the requested details to Twitter. Twitter uses this information to log you in.

In summary, you (Resource Owner) grant access to the Twitter web application (Client) to access your profile information stored in Google (both Authorization Server and Resource Server) so that Twitter can identify you and log you in with details fetched from Google.

Scope, Claims and Grants

In the context of OAuth 2.0, Scopes, Claims, and Grants enable secure and flexible authorization. These together define what resource a client can access, what information is shared with them, and how the authorization is obtained. In this section, we’ll review these concepts. 

Scopes

Scope in OAuth 2.0 restricts access to an application. An application can request specific scopes depending on the requirement. The access token issued to the application will then be limited to the granted scopes. OAuth doesn’t specify particular scope values; these depend on each service provider’s architecture and requirements.

Users need to understand what level of access they are granting to the application, which will be presented to the user on the consent screen. 

Scopes can be read-only or write-access. For instance, read-only scopes limit the client to viewing data, while write access allows data modification. Hence, it’s critical to use the correct scopes.

Continuing with the Twitter example, when you create an OAuth application on Twitter, it asks you what scopes you want to allow. Some scopes like tweet.read, follows.read grant read-only access, allowing the client only to read tweets and followers. In contrast, scopes like tweet.write, follows.write, allow the client to post tweets, and follow people. Refer to Twitter OAuth2.0 scopes for more details.  

Claims

Claims refer to information about a user or client included in the token. Claims provide details about the token, the token holder, and other metadata. Common claims include “iss” (issuer), “sub” (subject), and “exp” (expiration time). Resource servers use these to validate the token and make decisions.

Custom claims can also be included in the token to convey more application-specific information, such as user roles and groups, enabling precise access control.

Grants

OAuth 2.0 framework has prescribed mechanisms on how the client can be granted secure access to the resource owner’s resources from the Resource Server. These are called Grant Types. 

There are two popular types of grants: 

• Authorization Code Grant
• Client Credentials Grant

Authorization Code Grant

This is one of the most widely used grant types suited for server-side applications. Compared to the basic OAuth2.0 flow, this flow adds an additional step for the client to obtain an authorization code used to obtain the access token, thus decoupling authorization from token issuance.

Proof Key for Code Exchange (PKCE)

Pronounced as ‘pixy’, this flow is an extension of the Authorization Code Grant designed to make it more secure. Unlike the former, PKCE introduces a dynamically generated code verifier and an associated challenge that adds additional security.

Client Credential Grant

This type of grant is used for machine-to-machine authentication where no user interaction is required. This involves a single request-response interaction where the client authenticates itself directly using clientID and secret.

Together, scopes, claims, and grants ensure that access to resources is granted in a controlled and secure manner.

Tokens in OAuth 2.0

Once a client is granted access (using grant type) to some resources on the resource server, the client does not need the user’s consent for every consecutive fetch of resources. The authorization server issues tokens for the client to access protected resources.

Tokens are time-bound credentials that allow secure access to protected resources. They ensure that even if a token is compromised, the potential damage is limited to its short lifespan.

There are primarily two types of tokens:

• Access Tokens
• Refresh Tokens

Access Tokens

The authorization server issues these tokens to the client upon successful authentication and resource owner authorization. The client uses these tokens to access protected resources on behalf of the user. 

Access tokens also carry information about the permission granted to the client application by the resource owner as defined by scopes. 

These access tokens have a short lifetime (“expiration period”) to mitigate the risk of unauthorized access. Typically, tokens are short-lived and often expire within a few minutes, depending on the policies set by the authorization server. 

Refresh Tokens

Unlike access tokens, refresh tokens have a longer lifespan and don’t expire unless the authorization server invalidates them. They are designed to refresh access tokens without any user intervention. 

Client applications use refresh tokens to request new access tokens when the current one expires. The process involves presenting the refresh token to the authorization server, which validates it and issues a new access token with the same scope and permissions.

Access and refresh tokens are issued during the OAuth 2.0 authorization process. After the client requests authorization, the authorization server generates an authentication code on behalf of the resource owner, which the client uses to exchange for access and refresh tokens from the authorization server. 

OAuth 2.0 Flow

OAuth 2.0 provides a secure and efficient way for third-party applications to interact with resource servers using access tokens. Here’s a step-by-step breakdown of how OAuth 2.0 works:

1. The client application requests authorization from the resource owner to access a protected resource by specifying the desired scopes and grant type.
2. The resource owner grants authorization to the client.
3. The client requests an access token from the authorization server.
4. The authorization server issues an access token limited to the specified scopes.
5. The client uses the access token to access the resource server on behalf of the resource owner.
6. The resource server validates the access token with the authorization server.
7. The resource server grants access to the requested resource.

Security Considerations

When implementing OAuth2.0, organizations must prioritize security to protect sensitive information and prevent unauthorized access. Some of the key considerations include:

• Safeguard Tokens: Encrypt and store all access and refresh tokens securely and transmit them only over secure channels (HTTPS). Implement token rotation mechanisms to limit the impact of token compromise. 
• Protect Client Secret: Always store the client secrets securely on the server and avoid exposing them in public clients like mobile apps. Use strong, unique secrets for each client.
• Use State Parameters: Always include and validate the state parameter in authorization requests to prevent cross-site forgery (CSRF) attacks.
• Always Use PKCE: PKCE helps prevent authorization code interception attacks, so implement it for all clients, regardless of their type.

OpenID Connect

OAuth2.0 focuses on authorizing third-party applications to access users’ resources. OpenID Connect (OIDC) extends this by adding identity authentication. By doing so, OIDC standardizes the process of users logging in to access third-party applications, thus providing a seamless user experience while securely managing user identities. 

With its added authentication components, OIDC leverages OAuth 2.0 to verify user identities and fetch basic profile information about the users.

This combination of authentication and authorization allows for Single Sign-On (SSO), making it easier for users to access multiple applications with a single login. 

Core components of OIDC include:

• OpenID Provider (OP): Similar to the Authorization Server in OAuth, it authenticates users and issues tokens.
• End-user: The user whose information is contained within the ID token.
• Relying Party (RP): Similar to a client in OAuth, it relies on the OP to authenticate and retrieve user information.
• ID Token: A JSON Web Token (JWT) issued by the OP contains user information (claims) about the authenticated end-user and allows the client application to verify the user's identity.
• Claim: The end user's properties, such as their name and email, that help the RP identify the user.
• Userinfo Endpoint: An endpoint provided by an OpenID provider where client applications can retrieve information about the user, such as their name, email, etc.
• Discovery Endpoint: This URL provides metadata about the OpenID provider’s configuration, such as endpoint URLs, supported scopes, etc. 

In this section, we understood OAuth 2.0 and the benefits it brings to working with third-party applications. From understanding the flows and tokens to decoding scopes and claims, we saw how it makes authorization a breeze. We also touched upon OIDC, an extension of OAuth 2.0 that adds the authentication layer, making it a complete authentication and authorization framework. Read our blog post on implementing OIDC SSO using Google to understand the complete implementation process.

In the next section, we’ll look at Single Sign-On (SSO), which builds on the principles of OAuth 2.0 and OIDC and enhances the user experience and security.