A Deep Dive into OAuth 2.0 for Seamless Data Access

When we talk about OAuth, are we talking about Authentication or Authorization? Well, OAuth stands for Open Authorization and is an open standard that allows the websites or applications to talk to each other on your behalf.

You might be wondering why would you want applications to talk to each other on your behalf anyways? Let's understand this via a use case:

Let's say you want to create a social media management application called Socialite. This app can post to multiple social media account once without you having to log in to different social media accounts and posting the same post again and again. Sort of an automation.

You might have already witnessed this feature on Instagram, where before posting the post, you are nudged as to whether you want this post to be posted on Facebook as well. But that is only limited to Facebook and Instagram. Our goal is to integrate multiple social media accounts such as Twitter, Facebook, Instagram, TikTok, etc.

We can create this feature easily using OAuth. We can divide the whole process into four segments:

Web Sequence diagram for Oauth2.0 flow

User Interaction

• First, the user logs into Socialite and navigates to the section for integrating social media accounts. This is where the user chooses which social media, they want their post to be posted.
• The user then selects Twitter from many other alternatives.

Authorization Request

• Now, our application, Socialite initiates the OAuth process by redirecting the user to Twitter's Authorization Server.
• The user is prompted to log in to their Twitter account (if not already logged in) and grant our Socialite application permission to post tweet on their behalf.

Authorization Grant

If the user grants the permission, Twitter's Authorization Server issues an OAuth access token to our Socialite application. This access token has limitation though, we can only post, we can't follow/unfollow, block, or even change the user credentials.

There are several types of authorization grants in OAuth, each serving a specific purpose. Here are some common examples.

Authorization Code:

• The client redirects the user to the authorization server with a request for authorization.
• The user authenticates and grants permission.
• The authorization server returns an authorization code to the client.
• The client exchanges the authorization code for an access token.

1Authorization Code: abcdef123456

Implicit Grant:

In the Implicit Grant flow, the access token is directly issued to the client without the intermediary step of obtaining an authorization code. This flow is often used in browser-based applications.

1Access Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Resource Owner Password Credentials Grant:

In this grant type, the user's username and password are directly exchanged for an access token. This flow is typically used when the client is highly trusted with the user's credentials.

1Username: user@example.com
2Password: password123

Client Credentials Grant:

The Client Credentials Grant involves the client using its own credentials (client ID and client secret) to obtain an access token directly.

1Client ID: abc123
2Client Secret: xyz456

Refresh Token:

While not an authorization grant itself, the refresh token is worth mentioning. In certain flows, an access token is accompanied by a refresh token. The refresh token can be used to obtain a new access token without requiring the user to re-authenticate.

1Refresh Token: sf3g98fcye7654oqw321qgqw0few25flawt3

It's important to note that the actual format and structure of these tokens or credentials can vary based on the implementation and the specific requirements of the authorization server.

Access to Protected Resource

• Our Socialite uses the access token to make requests to the Twitter API (the "Resource Server") to post tweets.
• The Twitter API validates the access token and, if valid, allows our Socialite application to post tweets on behalf of the user.

If you would like to understand how Authentication / Authorization work on a basic level, you can refer to this article that I posted a few months back:

How Authentication Works: A Step-by-Step Explanation of the Process Behind Signing Up and Logging In

I recently wanted to build a project where I was required to have a feature to authenticate users.

Components of Auth

OAuth involves several components that work together to enable secure authorization for third-party application (Socialite) to access protected resources (posting tweets or following users) on behalf of a user. The primary components are:

• Resource Owner (User): The resource owner is the user who owns the data or resources that the third-party application is seeking to access. For example, this could be an individual user on a social media platform or an email service.
• Client (Third-Party Application): The client is the third-party application that is requesting access to the user's resources. It could be a web or mobile application. The client initiates the OAuth process.
• Authorization Server: The authorization server is responsible for authenticating the user and obtaining their consent to grant access to the client. It issues access tokens to the client after successful authorization. The authorization server is often provided by the service that hosts the user's data (e.g., Google, Facebook, Twitter).
• Resource Server: The resource server hosts the protected resources (user data) that the client is trying to access. It verifies the access token provided by the client and, if valid, grants access to the requested resources.
• Authorization Grant: The authorization grant is a key component in OAuth, representing the user's consent to allow a client (third-party application) to access their protected resources. It is obtained by the client during the authorization process and is used to request an access token.
• Access Token: The access token is a credential that the client presents to the resource server when making requests for protected resources. It represents the authorization granted to the client. Access tokens are short-lived and are used to authenticate the client in subsequent requests.
• Refresh Token: Some OAuth flows involve the use of refresh tokens. A refresh token is a long-lived credential that can be used to obtain a new access token when the current one expires. This helps maintain a seamless user experience without requiring the user to re-authenticate.
• Scope: The scope parameter defines the extent of the access requested by the client. It specifies what actions the client is allowed to perform on behalf of the user. For example, a scope might include read-only access or read-write access.

Conclusion

In conclusion, OAuth (specifically OAuth 2.0) is an open standard protocol that provides a secure and standardized way for third-party applications to access protected resources on behalf of a user, without exposing the user's credentials. It is widely used in various contexts, such as social media integration, calendar applications, and other scenarios where secure access to user data is needed.