oAuth2.0 is a security standard that is used in many applications these days. One will find two predominant perspectives of this standard: the one that the client experiences and the other that the developer experiences. This blog aims to bring these two perspectives to you in the form of a story, and along the way you will learn how it works, the most commonly used flow — the authentication flow, how you can use it as a developer and so on…
Before we begin, here is a background of what we are going to look at:
So let’s start. A long time ago — this happened
But then this happened too —
But people eventually found out and then this happened —
They agreed upon standards to access info from one service to another, which makes sense given the massive breaches and court cases.
And that’s how oAuth2.0 came into the picture —
Plot 1: The oAuth2.0 flow — visible steps to grant consent
The Authorisation code flow ~
Note: S1 is service 1, S2 is service 2 Everything starts with a requirement. Let’s say I stumble on a website which helps me write blogs. The website is serviced by Service 2. After writing one, I want to send all my friends the link to that blog. I have their emails listed as my friends on Service 1. The question is, how can Service 2 help me out? Let’s find out:
Note: The offer that service 2 provides is something that you need to look out for as a developer of the service, check out plot 2 for the same.
1. “You can choose your email provider and then we can mutually agree on using the contact emails you have on that email provider. ”, said Service 2:
2. Client Redirects my browser to my email service [i.e. Authorization server]
The client sends the clientID, redirectURI, responseType and the scopes that it needs to the Auth server when it makes the browser redirect to Service 1 [the email service].
!!Terminology alert!!
So now, what I see in the front-end is ~
3. I may / may not give my consent for the scopes requested
!!Terminology alert!!
If I don’t consent, the Auth server redirects me back to the Service without giving the permissions. But if I do give my consent then —
4. The Authorization server redirects to Service 2 website using the redirect URI and gives the necessary permissions …that simple? Actually, there is more that goes into giving the permissions. It can roughly be divided into 3 steps:
So now, the client received permission to access my email list and that is the only thing it has access to. But what is this Access token? How is it different from the Authorization Code? Also, what is a Client's secret?
!!Terminology alert!!
Apart from the main difference i.e. when they are used and who uses them as mentioned above in the image ..there is a difference between their structure and usages:
5. Finally I can allow Service 2 to use my contacts and send my contacts the link to my blog :)
The end.
Plot 2: How service 2 created that option to offer — invisible steps where the 2 services agree on a secure way to exchange information
Client and authorisation servers establish a working relationship so that they can offer the resource owner functionalities without requiring the resource owner to provide the same information again.
Now the client can use the clientID and client secret to create an oAuth2.0 flow on its platform for users [resource owners] to use.
The end
Note: The Auth Server and the Resource Server may / may not be played by the same server/org. The Auth Server might be a 3rd party service that the Resource Server trusts and not the other way around because Resource Owner’s data is with the Resource Server.
And that’s it. Now you know both sides of the oAuth2.0 picture and can effectively use it in your application. If you have any doubts you can ask me or you can ask anything in our slack. Here is also my blog. Until next time!