OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement
The OAuth dance is the authentication process performed by the Mule OAuth 2.0 provider, API, and client application. This authentication process conforms to RFC 6749.
OAuth Dance Authentication Flow
The OAuth dance authentication flow is illustrated in the following screenshot:
-
A token request is sent to the provider, specifying client application credentials as needed.
The credentials correspond to a client ID and secret generated by Anypoint Platform.
-
The Mule OAuth 2.0 provider returns a token.
-
An HTTP request is performed against the protected resource to which the OAuth 2.0 Access Token Enforcement policy is applied.
The protected resource must be linked with the API definition through Autodiscovery.
-
The OAuth 2.0 Access Token Enforcement policy intercepts this request and communicates with the provider to validate the token.
-
If the token is correctly validated:
-
The token is allowlisted and kept on the record until it expires.
Any further request that contains this token is not validated against the OAuth provider.
-
The associated client ID of the client application credentials is verified to ensure that the application has an active contract with the API.
This is not applicable to OpenAM providers.
-
-
The request is then forwarded to the resource.
-
An HTTP response is generated.
The requester obtains the authorization from an OAuth provider, instead of directly gaining access to the credentials of the client application. The client application owner owns the credentials and authorizes the provider to interact with the API. The protected resource determines that the user is authorized because it has a valid access token.
Example HTTP Request to a Protected Resource Using curl
In the following example, the protected resource is set to http://localhost:8081/simple.