OAuth 2.0 Distilled

Understand the OAuth 2.0 workflow along with the different use cases of each grant types.

OAuth 2.0 Distilled

I believe that most if not all software engineers at least have heard of OAuth or OAuth 2.0 in their career but some of them does not really understand it well (no offend including me back in the day). If you are like me this article will help shed some light.

Before we get to the topic, let us understand what is the difference between Authentication and Authorization.

Authentication: is the process of verifying who you are.

Authorization: is the process of verifying what you can do after you successfully authenticated.

Let’s get started. Shall we?

History

When there is a 3rd party application that want to access user resources from another application; user has to give their credentials to that application. The problem is that user expose their credentials to the 3rd party application and user have to change their password and revoke access. That is why OAuth come into play.

OAuth could solve this issue by enables resource servers such as Google, Facebook, Microsoft or your own implementation resource server to provide limited access to the resource owner’s resources such as username or email without exposing the resource owner’s credentials to the 3rd party application.

What is OAuth 2.0

OAuth 2.0 is an authorization protocol that enables 3rd party application to get limited access to resource owner’s resources without sharing their credentials. In simpler terms, OAuth 2.0 allows a user to sign in to an application using their social media account or other online service provider. When a user tries to log in to an application, the user is directed to the authorization server, which verifies their identity and requests permission to access their data. If the user grants permission, the authorization server provides an access token to the application. The application can then use this token to access the user’s data without revealing their credentials.

OAuth 2.0 Components

OAuth 2.0 consists of 4 components that work together to enable secure access to protected resources. These components include:

• Resource Owner: The user who owns the protected resource.
• Resource Server: The server that hosts the protected resource. That could be a Product Microservice.
• Client: The application that wants to access the protected resource on behalf of the user. That could be your own Frontend Angular or React Application or 3rd party integration services.
• Authorization Server: The server that verifies the identity of the user and issues access tokens to the client. If that is a monolithic application it could be live inside the Resource Server but if it is a microservice application that could be an independent service.

Together, these components work to authenticate the user and authorize the client to access the user’s protected resources. The client must obtain an access token from the authorization server in order to access the protected resource. The access token is a string that represents the authorization granted to the client and is used to authenticate the client when making requests to the resource server.

Grant Type

OAuth 2.0 provides several grant types that enable different types of clients to access protected resources. The grant types define the flow of the authorization process and the type of credentials that the client must provide to obtain an access token. We usually use JWT to generate and verify the token.

• Authorization Code: is the most common grant type used in OAuth 2.0. It is typically used by web applications that require access to the user’s protected resources. In this flow, the client first redirects the user to the authorization server, where the user authenticates and grants permission to the client to access their protected resources. The authorization server then redirects the user back to the client, along with an authorization code. The client then exchanges the authorization code for an access token.
• Authorization Code with PKCE (Proof Key for Code Exchange): is a more secure version of the Authorization Code grant type. It is designed to prevent certain attacks that can occur with the Authorization Code grant type, such as code interception attacks. It is most recommended for any clients especially with SPA (Single Page Application) or Mobile Application.
• Implicit: is similar to the Authorization Code Grant, but is designed for clients that cannot keep a client secret, such as JavaScript-based web applications. In this flow, the client requests an access token directly from the authorization server, using the user’s credentials obtained through a login prompt.
• Resource Owner Password Credentials: is used when the client already has the user’s credentials, such as in the case of a trusted first-party application. In this flow, the client sends the user’s credentials directly to the authorization server, which issues an access token directly to the client.
• Client Credentials: is used when the client needs to access its own protected resources, rather than the user’s protected resources. In this flow, the client provides its own credentials directly to the authorization server, which issues an access token directly to the client.
• Refresh Token: is useful in situations where the client needs to access protected resources over a long period of time, without requiring the user to reauthorize the client every time the access token expires. Usually if we want to implement remember me feature.

Workflow

The OAuth 2.0 workflow involves several steps for the client application to obtain an access token from the authorization server. Here is a high-level overview of the OAuth 2.0 workflow:

1. User initiates the OAuth flow: The user initiates the OAuth flow by clicking on a “Login with [Provider]” button on the client application. The client application redirects the user to the authorization server’s authorization endpoint, along with a set of parameters that include the client ID, the requested scope of access, and a redirect URI.
2. User authorizes the client application: The authorization server prompts the user to sign in and authorize the client application to access the requested resources. The user may be asked to provide their username and password or may already be authenticated with the authorization server.
3. Authorization server issues an authorization code: If the user grants authorization, the authorization server issues an authorization code to the client application. The authorization code is a short-lived token that can only be used once and is not suitable for accessing protected resources directly.
4. Client application exchanges the authorization code for an access token: The client application sends a request to the authorization server’s token endpoint, along with the authorization code, client ID, and client secret. The authorization server verifies the authorization code and client credentials and issues an access token to the client application.
5. Client application uses the access token to access protected resources: The client application includes the access token in the Authorization header of API requests to the resource server. The resource server verifies the access token and grants or denies access to the requested resource.
6. Access token expires and client application requests a new token: Access tokens are short-lived and typically expire after a certain period of time. The client application must obtain a new access token to continue accessing protected resources.

The use of access tokens and the separation of authentication and authorization responsibilities between the authorization server and the resource server make it a powerful tool for modern application development.

Conclusion

Overall, OAuth 2.0 is a powerful and widely used authorization protocol that enables third-party applications to securely access protected resources on behalf of the user. With its multiple grant types, it provides flexibility for different types of clients to access protected resources while maintaining security. It is an essential tool for modern application development, making it easier and safer for users to navigate the digital landscape.

If you like my work and would like to buy me a coffee please go this buymeacoffee link. Thank you :)