Authorization Code Grant Flow In OAuth 2.0
In my previous article I talked about different grant flows in OAuth 2.0. I think now you have a basic idea about authorization code flow.
Now lets go deep inside to this process and get a basic understanding about the flow. Before that, let’s get some idea about authorization code. WHAT IS AUTHORIZATION CODE? It is a temporarily code that is used to exchange with access token.
Sometimes when you login to a client application, you can see the buttons like connect with google or connect with Facebook. Have you ever wondered how this flow goes? Sometimes it may be a OAuth flow.
Step 1
When you click that button, client application direct you to the server whatever you click. This is the step 1. Client directed to the authorization server. In authorization server, user need to enter user id and password to login.
Request details
https://testapp.com/authorize?response_type=code&redirect_uri=<callback_url>&client_id=<client_id>&scope=<scopes>&state=<state>
Here’s a small explanation about parameters.
Response_type — This indicates what is the type of response that I am expecting at the end of the process.
Redirect_uri — This tells about where to send user after the authorization complete. And also this must match to the registered URL.
Client_id — This is the public identifier of the app and it’ll have received when the app registered.
Scope — This is indication what is the level that application want to access. You can indicate one or more scopes at a time.
State — This can use to indicate what actions should perform after authorization complete. Also this can use to prevent CSRF attacks.
Step 2
After a successful login, it shows a prompt saying that “This” application want to access your “these information”.
Step 3
After user accept that prompt, it will be redirected back to redirect uri. When it redirecting, it won’t come alone. Authorization code will also received by the callback url. But client really wants the access token.
Response details
http://website.com/login?provider=testapp&state=<state>&code=<issued code>
Parameters →
Code — authorization code that is generated by authorization server. It will use to exchange with access token
Step 4
Client application again goes to authorization server to exchange the authorization code with access token. After checking the authorization code, authorization server will return access token if it is a valid authorization code.
Request details
POSThttps://testapp.com/token?client_id=<client id>&client_secret=<secret>&grant_type=authorization_code&code=<issued code>
Response details
{“access_token”:”<access token>”,“refresh_token”:”<refresh token>”,“scope”:”<scope>”,“token_type”:”Bearer”,“Expires_in”:3600}
Parameters →
Client_secret — this is like password of the application.It ensure that the authorization code is made only from this application
Grant _type — This tells about the grant type that is in use
Access_token — It is generated using authorization code. I’ll use to get information from resource.
Refresh_token — it is used to exchange with access token when it is expired.
Expires_in — time in minutes that will take to expire the access token
Step 5
By using this access token client application can access to resources. Resource server only give permission for a valid access token. So it will check whether this token is valid or not before letting access.
Request details
GETAuthorization: Bearer accesstokenhttps://testapp.com/userinfo
IS THERE ANY EXTRA STEPS??
Have you ever wondered about using an authorization code to generate an access token. Isn’t it an extra step? What do you think?? Can you see the difference in arrows in this diagram. There are two types of arrows. Solid ones and dashed ones. Solid arrows are happen in front Channel. Others are happen in back channel. Access token is a highly secure one. So you can’t use front channel to communicate. That is the reason to use authorization code to generate token.
I think now you have a good understanding about authorization code grant flow. :-)
