Nav

About OAuth 2.0

This OAuth 2.0 Access Token Enforcement Using External Provider policy enforces the OAuth interaction, called the OAuth dance, between the OAuth 2.0 provider, API, and client application as described in RFC 6749. You can get a hands-on perspective of the OAuth dance by following the step-by-step procedure to build, run, and test the custom Mule OAuth provider in Anypoint Platform.

oauth+policy1
  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 user’s credentials. The user owns the credentials and authorizes the provider to interact with the API. The application has knowledge of the user’s authentication in the form of an access token.

About OAuth Provider Models

The OAuth 2.0 Access Token Enforcement Using External Provider policy supports HTTPS communication using a Mule OAuth 2.0 provider or other OAuth 2.0 provider, such as PingFederate, OpenAM, or Google. The provider verifies the validity of OAuth 2.0 credentials. The Mule OAuth provider can run on any application server that is in the same organization as your API protected by OAuth 2.0. For example, you can run the Mule provider on premises using a Tomcat server or in the cloud using CloudHub.

If you are using the deprecated AES OAuth policy provider for non-production environments, the policy as-is is working for you, and can accept tokens exchanged by HTTP (and not HTTPS), no change is required; otherwise, migrate to a Mule OAuth provider as follows:

  • Build a custom OAuth provider to replace the deprecated provider.

  • Remove policies from the affected APIs.

  • Reapply policies.

Your existing registered apps, client IDs, and client secrets continue working.