Nav

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

    Example: Configure an HTTP or Salesforce connector in the app to access OAuth-protected servers.

  • Protecting an API from unauthorized calls from client applications

    Example: Apply an OAuth 2.0 policy and your configured OAuth provider denies access to unauthenticated client apps.

You can use the following OAuth provider and policy pairs:

  • PingFederate provider and PingFederate OAuth Token Enforcement policy

  • OpenAM provider and OpenAM OAuthToken Enforcement policy

  • Mule OAuth 2.0 provider and OAuth 2.0 Access Token Enforcement Using External Provider policy

The API to which you apply an OAuth 2.0 policy supports HTTPS communication using a Mule OAuth 2.0 provider. The provider verifies the validity of OAuth 2.0 credentials.

Using a PingFederate or OpenAM provider is recommended. If you don’t want to contract with PingFederate or OpenAM, you need to build a Mule OAuth provider. Instead of building the provider from the ground up, you can download and import a custom Mule OAuth provider, developed by MuleSoft Consulting, into Anypoint Studio.

Migrating to the Mule OAuth Provider

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:

  • Customize the Mule OAuth provider to replace the deprecated one.

    On Exchange, you can download one provider that supports user/password or another that support LDAP.

  • Remove policies from the affected APIs.

  • Reapply policies.

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