If you have ever integrated any API your chances of encountering OAuth 2.0 are close to 90%. So how does it even work? Let's take a deep dive.

The Tale of a Token.

Whenever you visit a busy Mobile service center you are given a token and you just wait for your turn. In OAuth 2.0 this is an Access Token. Whenever you try to get data from an API endpoint, it will require you to provide an access token. Then comes the question who will give me the Access token?

In a service center, there is a dedicated counter that will check if actually have a Mobile phone from the same company the service center provides. Then it will hand over a slip with your queue number with the date and time mentioned so you can't use the token forever. Similarly, the API Access Token will have a timestamp and expiry so it has some limited duration of use.

Similar to the service center, the API provider will have a dedicated counter, the Authorization server. It will provide us Access tokens after checking that we are authorized user of their product.

But there is a problem.........

The service center has different departments for mobile phones, tablets, and VR Headsets. Many times mobile phone customers head towards the VR Headset department for some reason. To solve the problem the service center now started issuing tokens specific to the department, so now every token has a specific department. Similarly, for the API, we will have tokens authorized for specific resources most commonly known as scope, so if your token has email_read scope then it will not be able to read phone numbers.

All is well until one day some privacy-focused customers accuse the service center of taking that mobile data without consent.

What will happen now?

Now service center creates a consent system. Whenever the customer arrives first time it takes his consent to use data, then provides them the token. The API Authorization server similarly takes the consent of the user in the popular “Do you want to give XX App to use your email, phone” screen. It will provide you with an Authorization code which you can use to get an Access token.

Now that the privacy group is happy we have a new problem.

A few customers need to visit again to the service center but their token is invalid for a few hours so they have to take tokens again after filling in the consent form again. This makes customers unhappy. To fix the problem the service center now creates an additional token called Refresh Token. Now if the customer needs a next visit he can show the Refresh Token to get a new Access token without filing the consent form again so no “Do you want to give XX App to use your email, phone” again and again on API. Just save the refresh token in the user database and use it to get the access token at will.

The question is why 2 Access tokens and Refresh tokens? Why not combine them?

Because the access token is powerful, it provides unrestricted access to the customer to the service centers, and the security will let in the user with access by just its possession. This means the access token has to be time-limited to protect from security breaches. For getting refresh tokens visit the dedicated counter that is too inconvenient for multiple visits. What happens if Access tokens are used by some other person to get access to the service center?

This will be covered in part 2 of the Tale of Token