two legged and three legged OAuth 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.

 

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