OAuth 2.0 – Part 2

Authorization Grant

In continuation to my earlier blog, there are four different of scenarios, clients and authorization flows where OAuth can be deployed.  I will now discuss OAuth 2.0’s four different grant types:

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

Authorization Code

Authorization code flow is commonly used for server-side application (where source code is not exposed as a publicly so that client secret can be a private). This flow is based on redirection and supports refresh_token flow.

This grant type is used where the API application supports third party client to access user information on behalf of users such as Facebook, Google, Twitter, etc.. So user can use a number of client applications by giving specific authorization and scopes.

1. Client sends authorization core request to authorization server via its user-agent with certain properties such as client_id, scope, redirect_url and response_type.
2. Authorization server verify the client details successfully then it redirect to authorization page with authorization list, if user not logged in it get authentication by redirecting to login page (never share resource owner credentials to client).
3. Authorization server redirect back to the client with authorization code by redirecting. So the client receives authorization code.
4. Client request access_token to authorization server with client_id, client_secret, grant_type and authorization_code (some other parameters depends on api server implementation). This call happens on server side without passing through user-agent.
5. Authorization server validates the client details and authorization grant and if valid than it issues access_token (optionally refresh_token) to the client.

Implicit

Implicit flow is commonly used for web and mobile applications (where application runs in browser) and client confidentiality is not guaranteed. It does not support refresh_token to get access_token.

It is similar to authorization code flow but it passes the access_token directly to the client which means there is no intermediate code (authorization code).

This grant type is used where the API application wants to provide limited information to the client within a short time period. So the client application can use certain information to identify the users (like log in with Facebook, Google, etc…)

1. Client sends user authorization request to authorization server via its user-agent with certain properties such as client_id, scope, redirect_url and response_type.
2. Authorization server verify the client details successfully then it redirect to authorization page with authorization list, if user not logged in it get authentication by redirecting to login page.
3. Authorization server redirect back to the client with access_token by redirecting. So the client receives access_token to continue accessing protected resources.

Resource Owner Password Credentials

Resource Owner Password Credentials flow is used for same party native client application (where an application is installed on the device) and where there is trust relationship between resource owner and client.

It can be used directly as an authorization grant to obtain access token. In this flow, the client asks username and password to resource owner and it sends this along with client credentials to get access token since the client and the Authorization Server are controlled by the same party. It is opposed to redirection flow.

The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

• Resource Owner gives username and password to the client application.

• Client sends user credentials and client credentials to the authorization server with certain properties such as client_id, client_secret, username, password, scope, grant_type.

• Authorization server responds back to the client with access_token and optionally refresh_token then client receives and continues accessing protected resources.

Client Credentials

Client Credentials flow is used for to perform non-user related tasks (where the client application needs to access resources or call functions in the resource server, which are not related to a specific resource owner).

Client credentials are used as an authorization grant typically when the client is acting on its own behalf. In has several drawback when used for normal purpose.

1. Client sends client credentials to the authorization server with certain properties such as client_id, client_secret, grant_type.
2. Authorization server responds back to the client with access_token and optionally refresh_token then client receives and continues accessing protected resources.

Refresh Token Flow

 Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token expires. Issuing a refresh token is optional at the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token. Most of the grant types support refresh token flow.

1. Client requests access token to authorization server by client credentials with authorization grant.

2. The authorization server validates the client details and resource owner authorizations. If it is valid then it issues an access and refresh token to the client.

3. Client makes requests to get protected resource by passing access token to resource server.

4. Resource server validates an access token and if valid, it responds to the request.
5. Steps 3 and 4 repeat until access token expires. If client gets error for protected resource request then it skips to step 7, otherwise it makes another protected resource request.

6. Resource server returns invalid token error since access token in invalid.

7. Client makes new access token request to authorization server with client authentication and presenting refresh token. The client authentication is based in client type and authorization server policy.

8. The authorization server validate the client authentication and refresh token. If it is valid then it issues new access token  and optionally refresh token.

Conclusion

 OAuth 2.0 provides flexible flow with different authorization grant types based on different scenarios with different use cases. Some flows are complex and difficult to understand. However, once you learn more about OAuth 2.0 verbs and nouns like Authentication, Authorization, Client Application, Resource Owner, Authorization server, Resource Server, Authorization Code, Access token and Refresh token etc.., you will be able to choose grant type base on you requirement and flows.