Exploring OAuth 2.0 : A Guide to OAuth Roles and Protocol Flow

In my previous blog, I discussed the security issues and limitations in traditional client-server architecture, especially when it comes to granting third-party access to sensitive data. I introduced how OAuth 2.0 can mitigate these problems, but let’s take a deeper dive into OAuth roles and how they work in a real-world scenario.

The OAuth Roles

OAuth introduces four key roles that help manage secure authorization:

1. Resource Owner This is the entity that owns or controls the protected resources. When the resource owner is a person, it is referred to as the end-user. The resource owner grants permission to applications to access their resources.

2. Client The client is the application that is requesting access to the protected resource on behalf of the resource owner. The client is not always a person; it can be an application (mobile app, web app, etc.) acting on behalf of the resource owner.

3. Authorization Server The authorization server is responsible for authenticating the resource owner and issuing access tokens to the client. These tokens enable the client to access protected resources from the resource server.

4. Resource Server The resource server is where the protected resources are stored. It accepts access tokens from clients and serves the requested data based on the permissions granted by the resource owner.

Let’s Bring These Roles to Life: The Google Photos & Printing Shop Example

Imagine you’ve uploaded thousands of photos to Google Photos. Now, you need to print a few selected images, but instead of manually downloading each photo and transferring it to the printing shop (which takes up space and time), you want to share direct access to your Google Photos collection with the shop.

In the traditional setup, you’d have to share your Google account credentials with the printing shop. But this is a security nightmare — you’re handing over your username and password, which could lead to unauthorized access to your account.

This is where OAuth comes into play. Instead of sharing your credentials, OAuth allows you to grant the printing shop access to only the specific photos you want printed, without exposing your account details. Here’s how the four roles in OAuth help make this happen:

1. Resource Owner (You)

You are the resource owner. As the owner of the Google Photos account, you control the photos stored in the cloud. You can decide what data to share and with whom. In this case, you want to give the printing shop access to your photos for printing, but not full access to your Google account.

2. Client (Printing Shop’s App)

The client is the printing shop’s application that wants to access your photos. Rather than asking you for your Google username and password, the printing shop’s app will ask you to authorize it to access your Google Photos collection. It acts on your behalf, but it doesn’t store your Google credentials. Instead, it uses an access token to request the specific photos you’ve granted permission for.

3. Authorization Server (Google)

The authorization server is Google in this scenario. Google is the entity that authenticates you as the resource owner and issues an access token to the printing shop’s app. When you authorize the printing shop to access your photos, Google checks your identity (via a login or consent screen), and once you confirm, Google issues an access token. This token allows the printing shop’s app to access only the photos you’ve granted permission for, not your entire Google account.

4. Resource Server (Google Photos)

The resource server is Google Photos itself, where your images are stored. Once the printing shop’s app has received the access token from Google’s authorization server, it sends a request to the Google Photos API to retrieve the images you’ve authorized it to access. Google Photos (the resource server) checks the access token to ensure it’s valid, and if everything is in order, it serves the photos to the printing shop’s app for printing.

The OAuth Flow in Action

Here’s how the flow works step by step:

Step 01:

i) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.

ii) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.

In our example this is when the client (printing shop app) asks you, the resource owner, for permission to access your Google Photos. To give permission you will be directed to Google’s authorization server where you authenticate and grant the printing shop app permission to access your photos.

We will discuss more about Authorization Grant types in the next blog

Step 02:

i) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.

ii) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.

In our example this is when Google’s authorization server issues an access token to the printing shop app after validating the authorization grant presented by the client

We will discuss more about Access tokens in the upcoming blogs

Step 03:

i) The client requests the protected resource from the resource server and authenticates by presenting the access token.

ii) The resource server validates the access token, and if valid, serves the request.

In our example this is seen when client uses the access token to request specific photos from the resource server (Google Photos). And Google Photos (resource server) validates the access token and responds with the requested images.

To conclude, OAuth 2.0’s roles and protocol flow provide a secure and efficient way to manage access to your sensitive data, as demonstrated by the Google Photos and printing shop example. By separating authentication from authorization and using access tokens, OAuth helps mitigate the risks associated with sharing login credentials.

In the next blog, we’ll dive deeper into the different types of authorization grants in OAuth 2.0, exploring how each grant type works and when to use them for various scenarios. Stay tuned to further understand how these grants help facilitate secure and seamless interactions between clients, resource owners, and servers.