Understanding Workflow Of OAuth2.0 Authorization Grant Types

Method: POST
Content-Type: application/x-www-form-urlencoded
URL: https://your-authserver.com/authorize?
    response_type=code
    &client_id=<<Client_ID>>
    &redirect_uri=<https://clientapp.com/callback>>
    &scope=<<photo+offline_access>>
    &state=<<iX15fHJ415VMLClp>>

https://clientapp.com/callback? 
state=iX15fHJ415VMLClp
&code=5HcrmpuvvY98gZQw_gq9MivXui97kTaaLPQvGnj3x4o9sOhk 

Verify state query parameters in the URL. It should match with the value stored in this user's session so that will protect against CSRF attacks.

Step 4. Exchange authorization code to retrieve access token

The application's web server will go and talk to the OAuth server again with this authorization code to get an access token along with client authentication details including client ID and client secrets and do a POST request to the token endpoint.

grant_type should be set as authorization_code while calling the token endpoint.

Method:POST
Content-Type:application/x-www.form-urlencoded
URL:https://your-authserver.com/token?
grant_type=authorization_code
&client_id=wP_wLcKoURU8U_dELDYuGzvE
&client_secret=nnlTJLSMCp2yiVM74HTgSHL4YTSvZJsSVi6KrFRfsGWOkJa0
&redirect_uri=<<CallabckURL>>
&code=5HcrmpuvvY98gZQw_gq9MivXui97kTaaLPQvGnj3x4o9sOhk

Here

• grant_type=authorization_code: Indicates request contains authorization code.
• client_id: The Client ID you receive when you first create an application.
• client_secret: The Client secret provided by the Auth server during registration.
• redirect_uri: This should match the redirect URI used in the original request.
• code: Include the authorization code which is retrieved in the authorized endpoint.

Step 5. The application receives an access token in response

Now client app receives an access token and using this token client makes API requests to the resource server on behalf of the user. The response includes the access token and refresh token.

{
  "token_type": "Bearer",
  "expires_in": 86400,
  "access_token": "QKY08tqDO8aeNebZbfgUFs1PH-cjerK2WBvE9FZpYGgZHnS_nLfhKYTECMBmPF_chz5GipOA",
  "scope": "photo offline_access",
  "refresh_token": "8V2dMpzRqB5cQDvoTb6X_Msl"
}

Workflow of Implicit Grant Type

This grant type is used for mobile apps and SPA web applications where the client's secret confidentiality is not guaranteed.

Using this grant type, instead of issuing the client an authorization code, the client issued an access token directly.

This is also a redirection-based flow but the access token is given to the user agent to forward to the client application, so it may be exposed to the user and other applications on the user’s device.

In addition, this type does not authenticate the identity of the client application and relies on the redirect URI to serve this purpose. That is why it is having security concerns as if access tokens are exposed to resource owners and can be misused.

Below workflow diagram of implicit grant type is self-explanatory and demonstrates how an access token is generated from the authorization server and the same token is used to access protected resources.

Step 1. Calling Authorization endpoint by the client application.

The user is using a browser and visiting the client's website and they click the login button to use the app. The client redirects the request to the Auth Server by calling the authorized endpoint to grant user access and request an authorization code.

response_type should be set as a token while calling the authorized endpoint.

Method:POST
Content-Type:application/x-www.form-urlencoded
URL:https://your-authserver.com/authorize?
response_type=token
&client_id=<Client_ID>
&redirect_uri=<<https://clientapp.com/callback>>
&scope=<<photo+offline_access>>
&state=iX15fHJ415VMLClp 

Step 2. User Authorize the client application

The Auth Server requests credentials from the user and asks him/her to approve consent.

Step 3. User-agent receives access token directly with redirect URI

User-agent directly receives the access token in the callback URL. Here, the client does not need to perform extra steps to call the token endpoint.

https://clientapp.com/callback?
state=iX15fHJ415VMLClp
&access_token=QKY08tqDO8aeNebZbfgUFs1PH-cjerK2WBvE9FZpYGgZHnS_nLfhKYTECMBmPF_chz5GipOA
&expire_in=3600
&token_type=abc

Workflow of Client Credentials Grant Type

This grant type is designed for client applications who are resource owners. E.g. Console application or Windows services.

The best use case would be machine-to-machine communication when the client and resource owner are the same entity and a separate user entity is not involved in this workflow.

The below workflow diagram of client credentials type is self-explanatory and demonstrates how an access token is generated from the authorization server and the same token is used to access protected resources.

Step 1. Calling Token endpoint by client application

The client is directly calling the token endpoint to get an access token. grant_type should be set as client_credentials while calling the token endpoint.

Method: POST
Content-Type:application/x-www.form-urlencoded
URL: https://your-authserver.com/token?
grant_type=client_credentials
&client_id=<<CLIENT_ID>>
&client_secret=<<CLIENT_SECRET>>
&scope=<<abc>>

Step 2. The client application receives an access token directly

A client receives an access token after the auth server validates the client request and then the client makes an API access request using this token.

{
  "token_type": "Bearer",
  "expires_in": 86400,
  "access_token": "QKY08tqDO8aeNebZbfgUFs1PH-cjerK2WBvE9FZpYGgZHnS_nLfhKYTECMBmPF_chz5GipOA",
  "state": "iX15fHJ415VMLClp"
}

Workflow of Resource Owner Password Credential Grant Type

Designed for legacy applications and should not be used frequently.

The user provides their credentials directly to the client app that uses the credentials to obtain an access token from the auth server.

This grant type should be enabled on the authorization server if other flows are not viable. It is only used when applications are trusted by the user.

The below workflow diagram of password grant type is self-explanatory and demonstrates how an access token is generated from the authorization server and the same token is used to access protected resources.

Step 1. Calling Token endpoint by client application

The client is directly calling the token endpoint to get an access token. grant_type should be set as a password while calling the token endpoint.

Method:POST
Content-Type:application/x-www.form-urlencoded
URL:https://your-authserver.com/token?
grant_type=password
&username=<<Username>>
&password=<<Password>>
&scope=<<offline_access>>

Step 2. The client application receives an access token directly

A client receives an access token after the auth server validates the client request and ten clients make API access requests using this token.

{
  "token_type": "Bearer",
  "expires_in": 86400,
  "access_token": "QKY08tqDO8aeNebZbfgUFs1PH-cjerK2WBvE9FZpYGgZHnS_nLfhKYTECMBmPF_chz5GipOA"
}

Conclusion

In this article, we saw how different types of authorization grants work internally with the client app, auth server, and resource server to generate access tokens and access protected resources in the OAuth2.0 framework. Hope you find this information useful! Happy Learning!

Copyright Anupam Maiti. All rights reserved. No part of this article, including text, may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the copyright owner.