Let’s say you have created an API.
You want to protect it.
There are so many ways to do so. And one of the most efficient way to do is to protect it using OAuth 2.0.
As oauth0.com explains:
OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site, to another site, without having to expose their credentials.
If you protect your API using just a user name and password (Basic Authentication) you need to share those credentials with your clients. And probably the same credentials will be used to protect all your APIs in an application.
And also your credentials won’t be changed frequently , so if a malicious user somehow finds out your credentials , he can relaxedly hack all your APIs.
OAuth though provides temporary tokens. These are valid only for a specified time mostly a few minutes. So even if some one hacks one of your tokens , they will expire soon.
Here is how the entire flow works:
STEP 1 – Client asks for a resource :
We have four roles in OAuth 2.0 framework. Let’s discover them on the way.
The first one is the client. The client is the one who wants a resource exposed through an API.
The second one is the Resource Server. The API is deployed on the Resource Server.
A client asks a resource server for the API.
STEP 2 – Resource server wants a token:
The resource server asks for a token.
Authorization Server can give tokens. That is the third role in OAuth 2.0 framework.
The client then requests for a token to the Authorization Server:
Authorization Server too doesn’t trust the client. It asks for client credentials.
Client needs to get those from the Resource Owner. The Resource Owner is the fourth and final role in the framework.
STEP 3 – Client asks Resource Owner for credentials
STEP 4 – Resource Owner gives access details to the client
STEP 5 – Client gives credentials to Authorization server
STEP 6 – Authorization server then gives the token to the client:
The client credentials are already configured in Authorization server. The Authorization server checks the credentials sent by client against them and validates. If it is successful it gives a token.
STEP 7 – Client sends the token to the Resource Server and asks for the data
STEP 8 – Resource Server verifies the validity of the token with the Authorization Server
STEP 9 – Authorization Server verifies the validity
STEP 10 – Resource Server gives the data client requested for
As you see there are four roles here:
- Client – who wants a resource
- Resource Server – which has the resource
- Authorization Server – which gives tokens required by the resource server
- Resource Owner – who gives the credentials required to get a token to the client
That, is the basic flow of OAuth 2.0 framework .