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 an OAuth 2.0 policy to the API and use the corresponding OAuth provider to authenticate client applications.

    • 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

Using PingFederate or OpenAM is recommended.

About the Mule OAuth Provider

If you do not want to contract with an organization, such as PingFederate or OpenAM, you need to build a Mule OAuth provider. The OAuth 2.0 Access Token Enforcement Using External Provider policy supports HTTPS communication using a Mule OAuth 2.0 provider. 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:

  • 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.

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.