OAuth2 Framework…

This article will talk about the OAuth2 framework.

Background

I’m developing a photo-sharing application and, in the application, there is a provision to link user’s social media accounts like Instagram, Facebook etc.

The user opens the application and clicks on Connect Facebook.

What if the third-party photo-sharing application prompts the user to enter their Facebook account username and password in its realm?

Of course, this poses a potential security risk.

1. Sharing the credentials with a third-party application and letting it take full control of your Facebook account. They can do things beyond what they are entitled to do.
2. If the third-party application gets hacked, your Facebook account will also be at risk.

If we take a closer look at the first point, there are two key problems which we need to solve.

1. Credential Sharing.
2. Restricting or limiting access to protected resources.

The OAuth2 framework is introduced to solve these problems and going forward we will see how OAuth2 solve this problem in detail.

What is OAuth2 Framework?

It’s an open standard to securely delegate scoped access to protected resources.

Why is OAuth2 Framework?

To eliminate the need for credential sharing with a third-party application and to limit its level of access.

Let’s talk about some key terms in general…

What is a Realm?

It is basically a region of trust.

Given two realms A and B, components within realm A trust each other and the same goes with components in realm B trust each other. But components in two different realms do not trust each other.

What is Federation?

A Federation is an agreement between two realms by stating a trust relationship. This trust relationship helps two realms to communicate with each other.

What is Front Channel Communication?

Given a channel, if the communication between the systems is observable then it is called a front channel communication.

What is Back Channel Communication?

Given a channel, if the communication between the systems is not observable then it is called back-channel communication. It is more secure compared to front channel communication.

Let’s talk about OAuth2 in detail…

User

The one who has the authority to access the protected resources.

Client

An entity that is trying to access a set of protected resources. This is our third-party application.

Token

Represents the authority to access a protected resource on behalf of the user

About the OAuth2 Dance

Once the user logs in to the client application and tries to click Connect Facebook option for the first time, the dance begins. Frankly, this scenario is perfect for explaining the OAuth2 dance.

Let’s observe the dance from the balcony.

1. Once the user clicks on Connect Facebook, a resource access request will go from client to Facebook.
2. Facebook check the identity of the user and very the trust level of the client.
3. Facebook authenticate and authorize the resource access request with the help of the user.
4. Facebook issues a token to the client.
5. The client uses the token to access photos from Facebook

Here once the client gets the token from Facebook, they can issue it directly to Facebook to get access to photos.

Let’s observe the OAuth2 dance from the front row…

We already discussed client and user and we are good there. But let’s redefine the term token and talk about other terms involved in OAuth2 dance.

Given a client requested scope, the consent given by the user is an authorization grant.

Access Token

The access token represents the authority to access a protected resource on behalf of the user.

Authorization Server

The entity which is responsible for confirming the user identity and authorize the access request with the help of the user and is responsible for issuing the access token.

Resource Server

The entity, which is responsible for validating the access token received from the client and confirm the access.

Simply, in the above diagram, we can split Facebook into two — Authorization Server and Resource Server.

Resource Owner

It is simply the user.

Now let’s expand the above diagram properly. This is how the abstract protocol flow looks like.

OAuth2 specification does not mandate the authorization server and resource server as separate entities. This means the authorization servers can act as resource servers and vice versa.

What is the significance of the Authorization Grant…?

Here, the client is a browser-based web application. When a user clicks on Connect with Facebook, it gets redirected to the Facebook login page. Here users travel from one realm to another realm. The user enters their username and password and confirms their identity. Post that, the user will see a consent page to confirm the scope of access. In this scenario, the client is trying to access the album photos of the user. The user gives consent for the scope.

What if the authorization server returns the access token instead of the authorization grant?

Of course, this poses a potential security risk as the communication here is front-channel communication and the user agent can observe the communication. A malicious code can simply intercept the access token.

This is why in the front channel, the authorization server issues a one-time authorization grant.

Once the authorization grant is received by the client, it will do a server-to-server communication to get access token from the authorization server using the authorization grant. And this communication is simply a more secure back-channel communication.

Now let’s have a look at the above diagram once again.

This is how a complete abstract flow of OAuth2 Framework looks like.

Thank You for Reading 🙂

Seyed Sahil

Originally published at http://sydlabz.wordpress.com on June 13, 2021.