About OAuth 2 Policy Implementation

This following diagram shows how the OAuth 2 policy works with an existing OpenAM or PingFederate authorization server, or OpenID Connect Token Introspection endpoint, to protect access to your API version.

oauth implementation federated

  1. The user or application requests an access token using any valid grant type defined in the client application.

  2. The user or application sends a request with the access token. The federated policy validates the access token, provided as a well-formed query param or authorization header.

  3. The federated policy validates the token against the OAuth provider. To improve performance, Mule caches the call to the authorization server, which is only performed once during the lifetime of the token.

    When OpenId, PingFederate, or OAuth 2.0 Access Token Enforcement Using External Provider policies are in effect and your API is deployed under Mule 4, the client ID returned by the OAuth provider is validated by the Client Id Enforcement policy.

  4. All fulfilled requests in the flow are enriched with the information provided by the OAuth Provider when running under Mule 4, but information is not returned to the user. In releases earlier than Mule 4, this information was returned to the user.

Possible responses are:

Mule 4.0.0 or later

  • 200

    The token was successfully validated.

  • 400 Bad Request

    This Bad Request error can be caused by: no token sent, the token was sent both as query param and header, or the token was sent as header but does not have prefix "Bearer".

  • 401 Unauthorized

    The token is unauthorized.

  • 403 Forbidden

    This error could be the result of the validation to the OAuth Provider, the scopes validation, or the result of Client ID Enforcement Policy.

Mule 4 Implementation Scenarios

The following diagram represents a successfully validated token for OpenId, PingFederate, and OAuth 2.0 Access Token Enforcement Using External Provider policies:

oauth implementation diagram2

The following diagram represents a successfully validated for OpenAM policy:

successful validated openam

The following diagram represents an Unauthorized Token error:

unauthorized token

The following diagram represents a Forbidden Error from OAuth Provider error:

forbidden error

The following diagram represents Invalid Scopes error:

invalid scopes

The following diagram represents a Client Id Enforcement Validation Failed (Not valid for OpenAM Policy) error:

oauth implementation diagram3

The following diagram represents a Bad Request error:

bad request

Mule 4 HTTP Headers

In Mule 4, federation policies such as, OpenId Connect access token enforcement, as well as others that behave similarly set X-AGW- HTTP headers only for outgoing HTTP requests. This means that other API policies applied after the federation policy do not receive these headers, so that these later policies cannot make use of, for example, the x-agw-uid or x-agw-username extracted from and supplied by the federation policy.

Nevertheless, you can still retrieve user information from DataWeave.

To retrieve the user name, use:


To retrieve the UID, use:


We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.