
Grant Types in OAuth2.0
In my last article I mentioned about 5 grant types that can be used in Oauth2.0. This is a follow up for my last article where I ll try must best to explain about these grant types and how they work. If you are very new to oauth2.0 I ll recommend you to go through this you tube video before reading this article.(personally I like to have a little understanding before reading messy stuffs 😛)
Each of these grant types has different way of authorizing client to the user credentials(resources).
- Authorization Code Grant
Often developers use this grant types since it carries more security than all other grant types.Basically this grant type involves all the 4 roles in oauth context.(In this picture in spite of user we are showing a user agent -browser).

- Process will be initialized by user trying to get in to client(user end a GET request to client).
- Then the user will be redirected (302 response) to authorization server.(which is mention as authorization endpoint)
- Client will login to the authorization server with is username and password.
- Server will validate the user and redirect him to the client(to the redirection endpoint or call back URL)
- Client will be provided with a authorization code(which can be bargained for access token )
- Client will send the authorization code to authorization server(to the token endpoint) and gain access token(it will also gain a refresh token)
- Then the client will submit that access token to the resource server.
- Resource server will validate the access token (via introspect endpoint) and send the user credential to client(allowed credential).
Briefly saying client uses his authorization code to gain the access token and uses that access token to gain the resource needed.
when the authorization request is sent following parameters will be included in that.
response_typeRequired. Must be set tocode.client_idRequired. The client identifier as assigned by the authorization server, when the client was registered.redirect_uriOptional. The redirect URI registered by the client.scopeOptional. The possible scope of the request.stateOptional (recommended). Any client state that needs to be passed on to the client request URI.
In the response of authorization request will include:
1.code Required. The authorization code.
2.state Required, if present in request. The same value as sent by the client in the state parameter, if any.
Token request will include:
1.client_id Required. The client application's id.
2.client_secret Required. The client application's client secret .
3.grant_type Required. Must be set to authorization_code .
4.code Required. The authorization code received by the authorization server.
5.redirect_uri Required, if the request URI was included in the authorization request. Must be identical then.
Token response:
A success full token response may look like this.

Although this grant type offers better security it takes too many round trips before client access resources thus it has performance wise issue than other types.
2.Implicit Grant
As I mention in my last article this grant type is very much similar to authorization grant type expect here we don’t deal with authorization code. Straight way a client gets a access token as a response to his authorization request.
This means access token has to be shared along user-agent or native application which seems very unsafe to access token since application or clients run along with those can extract the access token from them. But in implicit type client doesn’t have to share his client secret which prevent him from above mentioned attacks.It depends on the redirect URI provided in the registration.
Normal flow of Implicit grant type will look like this

- User tries to use a service from client and then client will ask the user to authorize it to access his certain resources in some resource server.like facebook basic details.Then client have to sent a request to auth server.
- User will login to the auth server and grant permission to the client
- The auth server redirects the user-agent to the application redirect URI, and includes a URI fragment containing the access token.
- The user-agent follows the redirect URI but retains the access token.
- The application returns a webpage that contains a script that can extract the access token from the full redirect URI that the user-agent has retained.
- The user-agent executes the provided script and passes the extracted access token to the application.
Client can use the access token to gain resources until the token is expired or revoked. In implicit there is no refresh token so the whole process has to be repeated if user needs the same service.
implicit grant request include:
response_typeRequired. Must be set totoken.client_idRequired. The client identifier as assigned by the authorization server, when the client was registered.redirect_uriOptional. The redirect URI registered by the client.scopeOptional. The possible scope of the request.stateOptional (recommended). Any client state that needs to be passed on to the client request URI.
response to the above request will include:
access_tokenRequired. The access token assigned by the authorization server.token_typeRequired. The type of the tokenexpires_inRecommended. A number of seconds after which the access token expires.scopeOptional. The scope of the access token.stateRequired, if present in the authorization request. Must be same value asstateparameter in request.
note: this response is not a JSON
Implicit types is not so secure like authorization code type but it has better performance.Normally it is used when client is user agent based mobile or single page web application.
3.Client Credentials Grant
For this grant type we don’t need users to authorize the process.Simply client will ask the authorization server for access and get the access token by only using his own credentials(client credential).Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
This grant type should be only used with confidential clients where you don’t want a third party(user-agent) to interfere.If you are confused with this grant types take a example where google maps need some information from google cloud which holds the whole maps

A.The client authenticates with the authorization server and
requests an access token from the token endpoint.
B.The authorization server authenticates the client, and if valid,
issues an access token.
By simply submitting its credential client receives access token
client request will include:
grant_typeRequired. Must be set toclient_credentials.scopeOptional. The scope of the authorization.
response will look a like:

Normally client credential can be used when the resource owner is a machine rather than a client.like google
4.Resource Owner Password Grant
This grant type is used when there is trust a relationship between user and client.Here user gives his password and Id to client so that client can authorize it self with authorization server.Example you can login your facebook mobile application through your facebook ID and password.We should not use this grant type if we have suspicions about client.
Normal flow of password grant type will look like this:

0. user give his credentials to client
- client login to Oauth server with above user credentials and ask for access token
- Oauth server gives the access token
- client access resource from resource server using the access token.
grant request contains:
1.grant_type Required. Must be set to password
2.username Required. The username of the resource owner, UTF-8 encoded.
3.password Required. The password of the resource owner, UTF-8 encoded.
4.scope Optional. The scope of the authorization.
Oauth server response will look like this:

password grant type is used with the strong trust relationship with user and client. So user should make sure that client can keep up that relationship. The resource owner password credentials would normally be used by user agent client applications, or native client applications.
5.Refresh token
Actually this not a grant type mentioned in Oauth specification. So in normal practices there is only 4 grant types.(confused why i mention this as grant type?)Basically the flow of refresh token is different from these 4 grant types and not all the 4 grant types can produce refresh token. Authorization grant and resource owner password grant type can provide refresh token to the client.
So why we need this refresh token? access token are not long-lasting, they have their own expiry time so we use refresh token to ask for new access token.Because of this the refresh token is bound to the client to which it was issued.Even if the refresh token is provided it should be validated first.
The authorization server MUST:
1. require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),
2. authenticate the client if client authentication is included and
ensure that the refresh token was issued to the authenticated
client, and
3. validate the refresh token.
If valid and authorized, the authorization server issues an access
token
a typical refresh token request will include:
1.grant_type REQUIRED. Value MUST be set to ”refresh_token”.2.fresh_token REQUIRED. The refresh token issued to the client.3.scopeOPTIONAL. The requested scope MUST NOT include any scope
not originally granted by the resource owner, and if omitted is
treated as equal to the scope originally granted by the
resource owner.
successful response will look like

A typical flow for refresh token will look like this

summary
we can summarize the above 4 grant type like this:

Conclusion
This is just a rough idea of how 4 grant types and refresh token work but there is no better way to learn than practice.If you are going to implement Oauth2.0, first go through the specification(mentioned below) file and get better idea of oauth framework. Again these are just my understandings, so go through the below links and increase your (or have the correct) understanding.
References
- Oauth frame work specification :https://tools.ietf.org/html/rfc6749
- DigitalOcean :https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
- https://alexbilbie.com/guide-to-oauth-2-grants/
