---
schema_version: "1"
id: 88fe0ddb0f57006d024dfad8a0e71b6119d1d041bd67061a0977ba95bff0a8b7
title: OpenAM OAuth 2.0 Token Enforcement Policy
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-gateway/policies-included-openam-oauth-token-enforcement.md
canonical_url: https://docs.mulesoft.com/mule-gateway/policies-included-openam-oauth-token-enforcement
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 39ef86733cc5344fb5a0f8a7340df6e97c2361573049dec7a05bd78ff1ff0501
description: MuleSoft Documentation Site
latest: true
---
---
product: Mule Gateway
keywords: openam oauth 2.0 token enforcement, api gateway, flex gateway, gateway, policy
---

# OpenAM OAuth 2.0 Token Enforcement Policy

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>Policy Name</strong></p></td><td><p>OpenAM OAuth 2.0 Token Enforcement</p></td></tr><tr><td><p><strong>Summary</strong></p></td><td><p>Allows access only to authorized client applications</p></td></tr><tr><td><p><strong>Category</strong></p></td><td><p>Security</p></td></tr><tr><td><p><strong>First Mule version available</strong></p></td><td><p>v3.8.0</p></td></tr><tr><td rowspan="4"><p><strong>Returned Status Codes</strong></p></td><td><p>400 - Invalid token</p></td></tr><tr><td><p>401 - Unauthorized or Connection error when connecting to the authorization server</p></td></tr><tr><td><p>403 - Forbidden, invalid client application credentials</p></td></tr><tr><td><p>500 - Bad response from authorization server, or WSDL SOAP Fault error.</p></td></tr></tbody></table>

> [!IMPORTANT] This policy is only available in a Federated organization configured to use OpenAM as
> Client Management solution.

## Summary

The OpenAM 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 an OpenAM
authorization server. The token is obtained specifying the credentials of an
[authorized client application](https://docs.mulesoft.com/api-manager/latest/api-contracts-landing-page) when performing
the [OAuth dance](https://docs.mulesoft.com/api-manager/latest/oauth-dance-about).

Before applying this policy, make sure that you are familiar with its
[prerequisites](https://docs.mulesoft.com/api-manager/latest/about-configure-api-for-oauth)

When you apply the policy, you may optionally define a space separated list of
[OAuth 2.0 scopes](https://datatracker.ietf.org/doc/html/rfc6749) 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 (such as CONTRACTOR,
PUBLIC, EMPLOYEES\_ONLY, etc).

## Supported Grant Types

OpenAM supports two types of OAuth clients:

- A Confidential Client keeps its credentials confidential and includes the following grant types:

  - Client Credentials

  - Implicit

  - Resource Owner

- A Public Client shares its credentials with other parties and includes the following grant types:

  - Authorization Code

  - Implicit

  - Resource Owner

Each type of client supports three of the four OAuth grant types defined by the RFC. For this
reason, when configuring the OpenAM client, you can select only three of the four grant types. The
other grant type is unavailable because it belongs to the other client. You determine the public or
confidential property of the OpenAM client depending on the grant types you select.

## Performance

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 OpenAM OAuth 2.0 Token Enforcement Policy to use the Gateway proxy settings, specify
the following property:

anypoint.platform.external\_authentication\_provider\_enable\_proxy\_settings=<true|false(default)>

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

anypoint.platform.proxy\_host=localhost anypoint.platform.proxy\_port=8080

## 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 OpenAM side
configurable.

Token validation response example from the authorization server:

```text
{
    "uid":"john.doe",
    "mail":"john.doe@example.com",
    "scope":["uid","mail","cn","givenName"],
    "grant_type":"password",
    "cn":"John Doe",
    "realm":"/",
    "token_type":"Bearer",
    "expires_in":3600,
    "givenName":"John",
    "access_token":"fa017a0e-1bd5-214c-b19d-03efe9f9847e"
}
```

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

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

  #\[authentication.properties.userProperties.mail\]

> [!TIP] You can use the extra information to further tune your business logic.

## See Also

- [Client Applications and Contracts](https://docs.mulesoft.com/api-manager/latest/api-contracts-landing-page)

- [OAuth 2.0 Policy Prerequisites](https://docs.mulesoft.com/api-manager/latest/about-configure-api-for-oauth)

- [OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement](https://docs.mulesoft.com/api-manager/latest/oauth-dance-about)

- [Applying an OAuth 2.0 Token Validation Policy](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement)

- [Applying a Policy](https://docs.mulesoft.com/mule-gateway/policies-included-apply)

- [OpenAM](https://www.openidentityplatform.org/openam) identity provider

- [SAML 2.0](https://docs.mulesoft.com/access-management/external-identity#instructions-for-saml-configuration)

- [Configuring Mule Gateway API Autodiscovery in a Mule 4 Application](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4)
