two legged and three legged OAuth flow

Two-legged OAuth processing involves three parties: OAuth client, authorization server, and resource server. The OAuth client can be either the resource owner or the trusted entity that knows about the credentials of the resource owner. In other words, two-legged OAuth processing does not involve additional resource owner interaction.

Two-legged OAuth processing requires a grant type of resource owner password credential or client credentials.

The typical flow for two-legged OAuth processing involves the following activities:

1. An OAuth client initiates a request with an authorization server and receives an access token.
2. The OAuth client uses the access token to access protected resources on the resource server.

The following figure shows the two-legged OAuth processing flow.Figure 1. Two-legged OAuth processing flow

 

 

 

Three-legged OAuth processing involves four parties: resource owner, OAuth client, authorization server, and resource server. In other words, three-legged OAuth is a traditional pattern with resource owner interaction. In this case, a resource owner wants to give a client access to a server without sharing credentials.

Three-legged OAuth processing requires a grant type of authorization code.

In the three-legged OAuth flow, the client ID is a unique identifier for an OAuth client. The OAuth client uses its client ID and client secret or its client ID and client certificate to provide identity and optionally the credentials. In the specification, the client ID is client_id and client secret is client_secret. When you define an OAuth client profile for DataPower integration, the configured name is the client ID.

The typical flow for three-legged OAuth processing involves the following activities:

1. A user, as the resource owner, initiates a request to the OAuth client.
2. The OAuth client sends the resource owner a redirection to the authorization server.
3. The resource owner authenticates and optionally authorizes with the authorization server.
4. The authorization server presents a form to the resource owner to grant access.
5. The resource owner submits the form to allow or to deny access.
6. Based on the response from the resource owner, the following processing occurs:
   • If the resource owner allows access, the authorization server sends the OAuth client a redirection with the authorization grant code or the access token.
   • If the resource owner denies access, the request is redirected to the OAuth client but no grant is provided.
7. The OAuth client sends the following information to the token endpoint (authorization server).
   • Authorization grant code
   • Client ID
   • Client secret or client certificate
8. If verified, the authorization server sends the OAuth client an access token and optionally a refresh token.
9. The OAuth client sends the access token to the resource server to request protected resources.
10. If the access token is valid for the requested resources, the OAuth client can access the protected resources.

The following figure shows the three-legged OAuth processing flow.Figure 1. Three-legged OAuth processing flow

 

 

refs:

https://www.ibm.com/support/knowledgecenter/en/SS9H2Y_7.5.0/com.ibm.dp.doc/oauth_twoleggedflow.html

https://www.ibm.com/support/knowledgecenter/en/SS9H2Y_7.5.0/com.ibm.dp.doc/oauth_threeleggedflow.html