Contact Free trial Login

PingFederate OAuth 2.0 Token Enforcement

Policy Name

PingFederate OAuth 2.0 Token Enforcement


Allows access only to authorized client applications



Since Mule Version


Returned Status Codes

400 - Invalid token

401 - Unauthorized or Connection error when connecting to the authorization server

403 - Forbidden, invalid client application credentials

500 - Bad response from authorization server, or WSDL SOAP Fault error.

This policy is only available in a Federated organization configured to use PingFederate as Client Management solution.

The PingFederate OAuth 2.0 Token Enforcement Policy restricts access to a protected resource, by only allowing HTTP requests if the token provided in such request is a valid one and, optionally, the required OAuth scopes are fulfilled. The policy validates the token, by connecting to a PingFederate authorization server. The token is obtained specifying the credentials of an authorized client application when performing the OAuth dance.

Before applying this policy, make sure that you are familiar with its prerequisites

When you apply the policy, you may optionally define a space separated list of OAuth 2.0 scopes to be enforced by it. OAuth 2.0 scopes are a way to further limit access to a resource protected by OAuth. You may define words like READ, WRITE, or some others that make sense in the context of your organization (eg. CONTRACTOR, PUBLIC, EMPLOYEES_ONLY, etc).

Supported Grant Types

A client application created on a PingFederate Federated organization allows any combination of OAuth grant types: Implicit, Client Credentials, Resource Owner Password Credentials, and Authorization Code. On PingFederate side, you can enable or disable any combination of grant types. For the OAuth dance to be successful, the grant type to be used should be enabled in both, PingFederate and client application.


To improve performance, once a token is validated, by default, the token is cached by the system until it expires. Sometimes it is desirable to reduce or even disable the caching mechanism, for example to take into account revoked token scenarios.

To control token cached time (ie token cache time before retrying validation against the OAuth Provider), you may specify the following property:

anypoint.platform.max_federation_expiration_time=<a number equal or greater than 0>

Communicating to the OAuth provider through a proxy

To enable the PingFederate OAuth 2.0 Token Enforcement Policy to use the Gateway proxy settings, specify the following property:


Setting the previous property to true makes the policy use the runtime proxy settings if specified. For example:


Leveraging OAuth provider information

When a token is successfully validated by the OAuth provider, the provider sends back to the policy who requested the token validation, some extra information, including fields that are PingFederate side configurable.

Token validation response example from the authorization server:

    "cn":"John Doe",

The fields returned by the OAuth provider are processed by the policy, and:

  • For each field, the original request to the protected resource is enriched with HTTP headers in the form: X-AGW- + key=value

    • [Mule 4] As part of the policy configuration, you may choose to not Expose Headers. In that case, the request will not be enriched with X-AGW headers.

  • For further processing within the flow, the original unparsed response from the provider is made available for further processing.

    • [Mule 3] A flow variable ['_agwUser'] is setup. To access a particular value in the map, specify it directly using a MEL expression. For example:

    • [Mule 4] The information is stored in an authentication object. Supposing that a "mail" field is returned, its value can be accessed using the following DataWeave 2.0 expression:

You can use the extra information to further tune your business logic.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub