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.
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.
Your existing registered apps, client IDs, and client secrets continue working.