OAuth 2.0 Authorization Framework

OAuth 2.0 is an authorization framework which enables client to access protected resources on behalf of resource owner.

Earlier we had OAuth 1.0 which is now obsolete, was mainly specific to web client.  OAuth 2.0 framework is for web as well as non-web clients. OAuth 2.0 also simplified the interaction between OAuth roles.

Following roles are defined for OAuth 2.0

1.     Resource owner

2.     Client

3.     Authorization server

4.     Resource server

Refer below sequence diagram  to know how each role interact.

OAuth Roles Interaction

For accessing resources from ESB process, we may need mainly three roles. Here client itself is resource owner.

1.     Client

2.     Authorization server

3.     Resource server

Refer below sequence diagram.

Client needs to pass authorization grants to the Authorization server to get the access token.

An authorization grant is a credentials representing resource owner authorization to get access token.

There are four Authorization grant types: Authorization Code, Implicit, Resource Owner Password Credentials, and Client Credentials.

Normally we will use Client Credentials for ESB to get access token.

There are two types of client. One is confidential and another is public.

For confidential client, client needs to authenticate with client credentials with Authorization server. Authorization server will provide client id and client secret as credentials after client is registered.

Authorization server returns access token and optionally expiry token after client authentication is successful.

Flow Chart.

Logic can be following.

  1. Get access token (optional expiry token) from authorization server by presenting  client credentials(client id +client secret)
  2. Get the protected resources by presenting access token.
  3. If token expires, get the access token again by presenting client credentials.

If ESB process is accessing the protected resources less frequently, no need to store the access token in a cache. You can get fresh access token for every new request.  But when the process needs to access protected resource very frequently, it is better to cache the access token and use it for next time. Access token normally expires after certain duration. It that case, it would be good to store and reuse access token  for  better performance as every time for accessing protected resource requesting  access token is very much time consuming. Also you can use refresh token to get new access token if refresh token is available.

You may encrypt and store access token as required for better security. Some ESB tools come up with built in adapter for OAuth 2.0. You may also use native HTTP client adapter for this purpose. Using HTTP adapter, you may need to make   two HTTP calls. First call is to get access token and second call is to access protected resources.