OAuth 2.0 and OpenID Connect Pt.2
with Ash Ketchum and his Pokémons
In previous post we discussed about the need of a mechanism which can help people to authorize third parties to access their resources without the need of exposing their credentials.
In this post we will discuss more about the technical aspects of OAuth 2.0.Have a look at the below Code flow :
Let’s break down the process into smaller parts :
1.Request Authorization Code
In this step , the Application crafts a request to the authorization server with following details :
- Client Id : An ID that you get after registering with the Auth Server.
- Redirect URI : It is the place where the Auth Server has to respond .
- Response Type : The type of response that we are expecting (Auth Code/Token).
- Scope : The type of resources that an application wants access too.
2.Sign In and Consent
In this step , the authorization server redirects the client to a login page and verifies the authenticity of the user using his credentials for the site. Once the server verifies the credentials , the server asks the user about his consent which includes all the details that’ll be exposed to the requesting Application. After the user verifies and gives their consent the response is sent to the redirect URI which we sent in step 1 along with the Authorization Code.
3.Exchange Auth Code for Access Token
After receiving the authorization code , the Application sends the authorization code to the Authorization Server to request for the final Access Token which will enable us to eventually use the desired resource on user’s behalf.
Authorization Server verifies the Code along with the Application’s secret (only known to Application Owner) so that no one other than the Application can use this Code to generate access token even if they somehow got hold of our Auth Code , they still have to steal our “Application Secret” , which is actually difficult because it is only known to us (the Application).
After all the details are verified , the token is generated and sent back to the application.
4.Accessing Resource with the Token
Finally , we have our magical token. At this step the Application sends a request to the Resource Server with the access token , saying “Hey , I have this token which I got after the user’s permission , can you please let me in and get the following details ?” . The Resource Server verifies the token and lets the Application access the desired resources mentioned above.
Voilla , now our Application can access resources on User’s behalf without even forcing them to expose their credentials to us ? Cool , right?. However there are some things that we should notice here.
Let us understand what is a Front Channel and Back Channel to understand why this flow is much more secure than other mechanisms out there.
Front Channel :
The requests that go from your web browser to the server are sent via the front channel . The issue with the front channel is that your browser is very prone to attacks which might result in someone accessing the resources on your behalf without your knowledge.
We can see in the flow that the request for the Auth code goes through the front channel along with the client id and other details , these details are not so critical that’s why we can request them via the front channel.
But the token request is not sent via the browser but instead it is sent via the Application server to the Authorization server , this pathway is known as Back Channel.
Back Channel :
The medium that the Application Server uses to communicate with the Authorization Server is known as Back Channel . The advantages with Back Channel is that we can implement our own security mechanisms such as encryption .
The request for Access Token is sent via the back channel to ensure that client side vulnerabilities are avoided as much as possible .
In next post we will discuss about OpenID Connect to implement authentication based on OAuth 2.0 . Till then stay positive and test negative. 😃