---
schema_version: "1"
id: 5f1f45babd0b22e408b4ef65f63591e04122f1efc1706beb6dc13eff93b4c831
title: Client ID Enforcement Policy
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-gateway/policies-included-client-id-enforcement.md
canonical_url: https://docs.mulesoft.com/mule-gateway/policies-included-client-id-enforcement
source_site: docs.mulesoft.com
content_type: documentation
content_hash: ec0649a5d6ecf312c51e81518abda6fda7c055465e694122c90c234407da0c6d
description: MuleSoft Documentation Site
latest: true
---
---
product: Mule Gateway
keywords: clientid enforcement, api gateway, mule gateway, gateway, policy
---

# Client ID 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>Client ID 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>Compliance</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>401 - Unauthorized or 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>

## Summary

The Client ID Enforcement policy restricts access to a protected resource by allowing requests only
from registered client applications. The policy ensures that the client credentials sent on each
request have been approved to consume the API.

When a client application is registered in Anypoint Platform, a pair of credentials consisting of a
client ID and client secret is generated. When the client application requests access to an API, a
contract is created between the application and that API. An API that is protected with a Client ID
Enforcement policy is accessible only to applications that have an approved contract.

When you apply a Client ID Enforcement policy, access to your API is tracked by reporting the client
ID along with the analytics events. You can configure Mule runtime engine (Mule) to encrypt all
sensitive information that pertains to policies, contracts, and initialization data.

Default policies that internally enforce client application credentials include:

- [Rate Limiting: SLA-Based Policy](https://docs.mulesoft.com/mule-gateway/policies-included-rate-limiting-sla)

- [OAuth 2.0 Access Token Enforcement Using Mule OAuth Provider Policy](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement)

- [PingFederate OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/mule-gateway/policies-included-pingfederate-oauth-token-enforcement)

- [OpenAM OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/mule-gateway/policies-included-openam-oauth-token-enforcement)

- [JWT Validation Policy](https://docs.mulesoft.com/mule-gateway/policies-included-jwt-validation)

Although token enforcement policies can optionally skip client validation, it is recommended that
you enforce the validation to ensure that the token is associated to an approved contract.

## Configuring Policy Parameters

### Mule Gateway

When you apply the policy to your API from the UI, a list of parameters are displayed based on
whether your environment includes Mule or non-Mule applications.

#### Configuring the Parameters

For Mule applications, the following parameters are displayed:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Parameter</th><th>Description</th><th>Required</th></tr></thead><tbody><tr><td><div><div><p>Credentials origin</p></div></div></td><td><div><div><p>Specifies from where in the request to extract the values:</p></div><div><ul><li><p>HTTP Basic Authentication Header: Requires credentials as part of the authorization header. The application consuming the API must use the basic authentication scheme to send the credentials in the requests.</p></li><li><p>Custom Expression: Accepts a DataWeave 2.0 expression for each client ID and client secret, indicating where to extract the credentials from the request. Use this option to send the credentials in a custom header or any other format. You can leave the field blank to configure the client secret requirement as optional.</p></li></ul></div></div></td><td><div><div><p>Must choose from one of the options.</p></div></div></td></tr><tr><td><div><div><p>Client ID Expression</p></div></div></td><td><div><div><p>The DataWeave 2.0 expression to use for obtaining the client ID from API requests.</p></div></div></td><td><div><div><p>Yes.</p></div></div></td></tr><tr><td><div><div><p>Client Secret Expression</p></div></div></td><td><div><div><p>The DataWeave 2.0 expression to use for obtaining the client secret from API requests.</p></div></div></td><td><div><div><p>No.</p></div></div></td></tr><tr><td><div><div><p>Method &amp; Resource conditions: Apply configurations to all API methods &amp; resources</p></div></div></td><td><div><div><p>Choose this option if you require the policy to be applied to all the methods and resources associated with the API.</p></div></div></td><td><div><div><p>Must choose from one of the options.</p></div></div></td></tr><tr><td><div><div><p>Method &amp; Resource conditions: Apply configurations to specific methods &amp; resources</p></div></div></td><td><div><div><p>Choose this option if you require the policy to be applied to only specific methods and resources associated with the API.</p></div></div></td><td><div><div><p>Must choose from one of the options.</p></div></div></td></tr></tbody></table>

## How This Policy Works

Before a client application is allowed to consume an API protected by a Client ID Enforcement
policy, the client application must request access to the API. After an approved contract exists
between the client application and the API, every request must include the client application
credentials in compliance with how the policy is configured.

For example, if the policy is configured to expect a client ID and client secret as query
parameters, the application must send those credentials in the request. To enforce this, add a
`client-id-required` RAML trait to the API specification:

traits: client-id-required: queryParameters: client\_id: type: string client\_secret: type: string

Apply the trait to the resources or methods using the `is` RAML attribute:

/example: get: is: \[client-id-required\] description: Example description

## Configuring How the Policy Obtains Credentials

You can configure the policy to extract either both the client ID and client secret, or only the
client ID from the HTTP request by using a variety of custom DataWeave 2.0 expressions. The
following examples use a client ID of '1234' and a client secret of 'abcd'.

### Obtaining Credentials Using HTTP Headers

Example request using curl:

```text
curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd"
```

Example DataWeave 2.0 expression to be used when configuring the policy:

```text
#[attributes.headers['client_id']]
#[attributes.headers['client_secret']]
```

In this example, the policy is configured to expect two headers: client\_id and client\_secret, with
the pair of credentials. The policy is flexible to allow other types of headers also. This is the
default configuration for the policy.

### Obtaining Credentials Using HTTP Query Parameters

Example request using curl:

```text
curl "http://localhost/myResource?client_id=1234&client_secret=abcd"
```

Example DataWeave 2.0 expression to be used when configuring the policy for Mule 4:

```text
#[attributes.queryParams.'client_id']
#[attributes.queryParams.'client_secret']
```

In this example, the requester must send the two specified query parameters with the request.
Although this is a supported configuration, it poses possible security risks. The recommended method
is to use headers. DataWeave 2.0 is fully supported in Mule 4 as wells as a subset in Omni.

### Obtaining Credentials Using HTTP Request Payload (Mule only)

Example request using curl:

```text
curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST
```

Example DataWeave 2.0 expression to be used when configuring the policy:

```text
#[payload.client_id]
#[payload.client_secret]
```

Although you can configure the policy to obtain the credentials from the request payload, this
option is not recommended because it is harder to reflect in the API specification.

### Obtaining Credentials Using Basic Authorization header

Example request using curl:

```text
curl "http://localhost/myResource" -u 1234:abcd
```

## Configuring API Specifications

The Client ID Enforcement policy requires changes in your API specification to implement the
credentials requirement. You can find the RAML or OAS snippet link containing the RAML or OAS code
you need to add to the API specification in the corresponding policy. You can access this code from
the list of applied policies in the Policies tab of your API specification in API Manager.

## Policy Output

When an HTTP request is performed against a protected resource for which the Client ID Enforcement
policy is applied, and the client application credentials are invalid or unauthorized, the HTTP
response includes a WWW Authenticate header with the following values:

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>Custom mode</strong></p></td><td><p>Header 'WWW-Authenticate'='Client-ID-Enforcement'</p></td></tr><tr><td><p><strong>Basic Auth mode</strong></p></td><td><p>Header 'WWW-Authenticate'='Basic realm="mule-realm"</p></td></tr></tbody></table>

For SOAP applications, the response is a SOAP error.

## See Also

- [Rate Limiting: SLA-Based Policy](https://docs.mulesoft.com/mule-gateway/policies-included-rate-limiting-sla)

- [OAuth 2.0 Access Token Enforcement Using Mule OAuth Provider Policy](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement)

- [PingFederate OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/mule-gateway/policies-included-pingfederate-oauth-token-enforcement)

- [OpenAM OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/mule-gateway/policies-included-openam-oauth-token-enforcement)

- [JWT Validation Policy](https://docs.mulesoft.com/mule-gateway/policies-included-jwt-validation)

- [Managing API Instance Contracts on API Manager](https://docs.mulesoft.com/api-manager/latest/manage-client-apps-latest-task)

- [Getting Client ID and Client Secret of a Registered Client App](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task)

- [OpenID Connect OAuth 2.0 Token Enforcement Policy](https://docs.mulesoft.com/mule-gateway/policies-included-openid-token-enforcement)

- [Mule Gateway Startup Encryption](https://docs.mulesoft.com/mule-gateway/mule-gateway-encryption-mule4)