About the OAuth Dance

The authentication process performed by the Mule OAuth 2.0 provider, API, and client application conforms to RFC 6749. This process is called the OAuth Dance.

  1. The client application requests a token from the provider.

  2. The provider returns a token.

  3. The client application includes the token either as an authentication header or a query parameter in a request to the API.

  4. The OAuth 2.0 Access Token Enforcement Using External Provider Policy intercepts this request and communicates with the provider to validate the token.

  5. The validated token is whitelisted and kept on record until expiration. Any further requests that contain this token are not validated against the OAuth provider.

  6. If the token is valid, the request is forwarded to the API.

  7. The API responds to the client application.

The client application gets authorization from an OAuth provider instead of directly gaining access to the credentials of the application user. The application user owns the credentials and authorizes the provider to interact with the API. The application knows the user is ok because it has the access token.

You can get a hands-on perspective of the OAuth dance by performing the tasks for building, running, and testing a Mule OAuth provider.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub
Submit your feedback!
Share your thoughts to help us build the best documentation experience for you!
Take our latest survey!