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.

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.

Security consideration is the most critical aspects when you are integration applications. Service end point should be protected from un-authorized access. Source, destination, middleware integration application or ESB support several authentication protocols. We should select the most suitable one on the basis of the scenario. Like cloud to cloud integration needs more security, so we may use Two-way SSL. By Two-way SSL we are authenticating users by their certificates. This is more secure than basic authentication. Similarly we can use SAML for federated SSO. Basic authentication can be used to connect intranet application. We can use NTLM for connecting to SQL Server.
Apart  from authentication and authorization, access control to the server, auditing, compliance requirement is critical for security.
I have come up with some guidelines where to use which authentication protocol on the basis of application capabilities. Please check below.

Source	Destination	Scenario	Recommended Authentication Protocol
Cloud Application	Middleware Integration  Application	Partner platforms are already integrated with Same IDP for federated SSO	SAML
Cloud  Application	Middleware Integration  Application	There is no common Identity Provider and Both support Two way SSL	Two Way SSL
Cloud Application	Middleware Integration  Application	Middleware exposing  third party resources	Oauth/Openid Connect
On-Premise  Application	Middleware Integration  Application	Application paltforms are already integrated with Same IDP  for federated SSO	SAML
On Premise Application	Middleware Integration  Application	Applications are in same  windows domain and Microsoft  Windows active directory  used as identity provider	Kerberos
Middleware Integration  Application	Cloud application	ESB is invoking external Application	TwoWay SSL
Middleware Integration  Application	Cloud application	ESB is accessing third party resources	Oauth/Openid Connect
Middleware Integration  Application	On-Premise Application	ESB is invoking On-Premise Application and LDAP server  is used for  technical account	LDAP based Basic authentication
Middleware Integration  Application	Database	ESB is  making database call using JDBC	Basic authentication
Middleware Integration  Application	SQL Server Database	Integration application  and database are in same windows Domain	NTLM
Middleware Integration  Application	Fileserver	Connect with SFTP protocol	Basic authentication
Middleware Integration  Application	External Application	This is mostly accessing cloud application where it is required to sign the rest request	Signing  the  request