Introduction
Lately, I have been working on the oAuth2.0 authorization framework and writing on the same as well. In my other posts, I have explained the basic concepts of oAuth2.0, Authorization Code grant type , Resource Owners Password Grant type as well. In this post, we will walk through the tutorial on oAuth2 implicit grant flow. It’s a variant of authorization code grant type with some differences –
- There is no requirement of authorisation code here.
- Authorization server sends back the access token to the client without the need of authorization code.
- There is no refresh token involved here.
- There is no client_secret involved either.
Implicit grant flow is designed for applications that access resources/APIs only during when the end-user is present and using the application. These type of applications cannot store confidential information like client secret.
With this tutorial on oAuth2 implicit grant flow, I hope to enrich your understanding of the subject.
When to use oAuth2 implicit grant flow
We can categorize oAuth clients in two broad segments – trusted clients and non-trusted clients. oAuth2 Implicit grant flow is suitable for the non-trusted clients. These application don’t have a secure way of storing client secret information. User agent based clients like web applications can’t store client_secret securely (one can easily access as these are client side web app) and makes use of oAuth2 implicit grant flow.
When using some websites like LinkedIn, you might have noticed that it asks permission to access your Facebook or gmail contacts for better experience. LinkedIn may use these contact information to invite new connections, syncing contacts or sharing information etc. You may have also noticed that some messenger mobile apps prompt to access the contact list of your GMAIL account to sync contacts or to invite them to the apps. These are some classic cases to use oAuth2 implicit grant flow.
Let’s dive deep to understand it!
Stakeholders in the Authorization Process
- Resource Owner (user) – A user or an application who/which owns a protected resource on the Resource Server.
- Resource Server (service/API server) – It’s the server that hosts the protected resource. This data/resource is to be shared with the client/third party application.
- Client – The client or third party application requests access to the resources/data (owned by Resource Owner) stored in Resource Server
- Authorization Server – It issues access tokens to the Client after the resource owner successfully authenticates itself and provides all the necessary authorization.
Concepts
- Authorisation Server exposes one point –
- ACCESS TOKEN end point – This is used to obtain tokens from the authorisation server.
- Client Id – The client must have a unique id and is called Client Id
- Access Token – To obtain the data from restricted resource, clients uses the Access Token. This has short lifetime.
Sequence Diagram
oAuth2-implicit-grant-flow-diagram
Flow Description
STEP 1
- If you look at the above sequence diagram, the flow starts when Resource Owner/User instructs the Client to access the its protected resource in the Resource Server. This is the point OAuth process kicks in.
STEP 2
Upon getting the user instruction to access a protected resource, the Client sends a request to the ACCESS TOKEN end point of with following parameters –
- client_id – As already described above, this is the unique identification number of the client.
- redirect_uri – This is the URL where the server will redirect the user after s/he completes the authorization process.
- state – Client sends a request to ACCESS TOKEN end-point with certain value in this parameter. When the AUTHORIZATION server sends a response back to redirect_uri, it sends back the value of state parameter unchanged. Then the Client checks this value to ensure that if it’s indeed same value it sent as part of token request. Thus, client can ensure that it receives the response for the correct request.
- scope – For which the Client is requesting authorization. These are space delimited list of scope string; for example – profile, email, location etc.
- response_type – It’s defaulted to token. This denotes that the request is for obtaining the ACCESS TOKEN.
STEP 3
- The Authorization sever verifies the client_id in the request with the stored client_id.
- It may also optionally validate based on the redirect_uri.
STEP 4
- Thereafter, it opens the sign-in web-page/dialog and also mention what all information (scope) will be accessed by the Client.
STEP 5
- User or the Resource Owner provides credential and also provides the consent that the Client can access the the list of scope.
STEP 6
- If the provided credential is correct, user is signed in and consents are recorded.
- If the user the does not provide the consent, the entire process halts and exception process kicks in.
STEP 7
- After successful signing in and record of user consent, Authorization server generates access token.
STEP 8
- Redirect the user’s browser to the URL specified in redirect_uri (in STEP 2) and the this response contains the access token. Authorization Server also passes the state parameter without change along with following information –
- access_token – Client uses this is the token in further calls to the actual resource. This token is passed in URI hash fragment (#). It’s to note that, this parameter will not be passed as query parameter.
- token_type – with value Bearer
- expires_in – This integer value is the TTL of the access_token
- state – The same value that was passed in Step#2
STEP 9
- Client will compare the value of state parameter to ensure that it’s the same value that client sent sent in Step#2. This is to avoid any CSRF attack.
STEP 10 & 11
- Client then uses the access token to hit the protected resource URL and accesses the protected data.
- When the access token expires, begin from Step#2.
Conclusion
Well, that’s all. I hope to have made it simple enough for grasping. Please let me know if you have any further question on the explanation so far. Following are some of the references that I have used for my own learning process.
