This article will talk about the OAuth2 framework.


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 in realm A and realm B trust each other. But components in two different realms do not trust each other.

What is Federation? 

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 as front channel communication.

What is Back Channel Communication? 

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

Let’s talk about OAuth2 in detail… 


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


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


Represents the authority to access a protected resource on behalf of 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 balcony. 

  1. Once user clicks on Connect Facebook, a resource access request to will go from client to Facebook. 
  2. Facebook check the identity of the user and very the trust level of client. 
  3. Facebook authenticate and authorize the resource access request with the help of user. 
  4. Facebook issues a token to client. 
  5. Client use 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 front row… 

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

Authorization Grant 

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

Access Token 

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

Authorization Server 

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

Resource Server 

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

Simply, in the above diagram we can split Facebook in to 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 Authorization Grant…? 

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

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

Of course, this pose 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, authorization server issues one-time authorization grant. 

Once authorization grant is received by client, it will do a server-to-server communication to get access token from authorization server using 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