About OAuth 2.0

In Anypoint Platform you work with OAuth solutions on the server and client side:

  • Accessing an OAuth-protected server from a client app

    For example, you create a client apps having an HTTP or Salesforce connector configured to access OAuth-protected servers.

  • Protecting an API from unauthorized calls from client applications

    For example, you apply the OAuth 2.0 policy to the API and use an OAuth provider to authenticate client applications.

Using one of the following external identity providers as an OAuth provider is recommended:

  • PingFederate

  • OpenAM

Alternatively, you can use the Mule OAuth 2.0 provider or another provider, such as the Google Provider. The disadvantage of using a provider other than the Mule, PingFederate, or OpenAM is the inconvenience of managing credentials. Using the Google Provider, you cannot take advantage of API Portal to provide credentials to application owners to access your API. You need to find another way to deliver the credentials.

About the OAuth 2.0 Access Token Enforcement Using External Provider Policy

The 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 in this section. In this section, you build, run, and test the custom Mule OAuth provider in Anypoint Platform.

  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.