When using the OIDC Token Enforcement policy in MuleSoft Anypoint API Manager, a 403 Forbidden / "Invalid Client" error may occur even when a valid token is presented.
This happens because Entra ID (Azure AD) does not pass the Client ID in the format expected by the API Gateway.
The API Gateway validates the "client_id" field in the request header or token claim. If Entra ID transmits the Client ID in a different field or format, the validation fails, resulting in a 403 Forbidden error. The "Skip Client ID Validation" option is unchecked in the API Manager policy configuration.
Additionally, if "Skip Client ID Validation" is checked and Entra ID tenant is used across different environments in Mule (Such as DEV, TEST, and UAT), the token generated in one environment will also work in another environment causing false positive scenario.
Root Cause:
Cross-Environment Acceptance: Tokens generated for an environment are signed by the same Entra ID tenant. If the API Gateway policy only validates the token's mathematical signature and skips deeper claim validation, it will accept tokens meant for other environments.
The "Invalid Client" Error: To stop the false positives, administrators often uncheck the "Skip Client Id Validation" box in the OpenID Connect policy. However, this triggers an "Invalid Client" error. Standard OIDC policies search the token payload for a claim exactly named client_id. Entra ID does not use this standard claim; instead, it passes the client identifier in either the appid or azp claim. The gateway finds a null value for client_id and incorrectly rejects the valid request.
To secure the environments and resolve the errors, you must move away from standard Client ID validation and instead validate environment-specific data within the token payload. Choose one of the following two solutions based on your API Gateway's capabilities.
This method allows you to remap the expected client ID claim and enforce strict audience matching.
Remove the OpenID Connect Policy: In your API Manager, remove the rigid "OpenID Connect access token enforcement" policy.
Add the JWT Validation Policy: Apply the "JWT Validation" policy to your API.
Map the Client ID: Locate the "Client ID Expression" field in the JWT Validation policy configuration. Change the default value (e.g., #[vars.claimSet.client_id]) to target the Entra ID claim: #[vars.claimSet.appid] (or #[vars.claimSet.azp]).
Enforce the Audience: Check the box for "Validate Audience Claim" and "Mandatory Audience Claim". In the "Expected Audience" field, input the exact Application ID URI specific to that environment.
Result: The gateway will now successfully read the Entra ID client identifier without throwing an error, and it will reject any token that doesn't have the correct matching environment Audience.
If you must use the standard "OpenID Connect access token enforcement" policy, you must bypass the client_id check but enforce strict OAuth Scopes to maintain the security boundary.
Create Environment Scopes in Entra ID: In your Entra ID App Registrations, create a unique custom scope for each environment under "Expose an API" (e.g., DEV.Access for DEV, and UAT.Access for UAT).
Configure the Policy: In your API Manager's OpenID Connect policy, check the box for "Skip Client Id Validation" (this prevents the "Invalid Client" error).
Enforce the Scope: In the same policy, locate the "Scope Validation Criteria" section. Enter the exact custom scope for that specific environment (e.g., type DEV.Access for the DEV API gateway).
Result: When a DEV token is sent to the UAT API, the gateway will check the scopes, see DEV.Access instead of the expected UAT.Access, and correctly reject the token, eliminating the false positives.
005321722

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.