MuleSoft Client ID Enforcement

Client ID Enforcement is MuleSoft's standard way to identify and control which applications access your APIs. Every consumer application registers in Anypoint Exchange and receives a unique Client ID and Client Secret pair. The Client ID Enforcement policy validates these credentials on every request, giving you full visibility and control over API consumers.

How Client ID Enforcement Works

When you apply the Client ID Enforcement policy to an API in API Manager, the API Gateway intercepts every incoming request. It extracts the client ID and client secret from the request (typically from headers), looks them up in Anypoint Platform's registry, and either allows or rejects the request.

Client ID Enforcement Flow

Client App Requests Access:
  1. Developer registers app in Anypoint Exchange
  2. Receives: client_id = "a1b2c3d4e5f6"
               client_secret = "z9y8x7w6v5u4t3"

API Call:
Client → GET /orders
  Headers:
    client_id:     a1b2c3d4e5f6
    client_secret: z9y8x7w6v5u4t3
         │
         ▼
[API Gateway: Client ID Enforcement Policy]
  Lookup client_id in Anypoint Platform registry
  Match found? ─── YES → validate client_secret
  Secrets match? ── YES → pass request to app
                    NO  → 401 Unauthorized
  Match found? ─── NO  → 401 Unauthorized
         │ (if passed)
         ▼
[Mule Application: process order]

Setting Up Client ID Enforcement in API Manager

1. Log in to Anypoint Platform and open API Manager
2. Select your API and click Policies
3. Click Apply New Policy
4. Search for Client ID Enforcement and click Apply
5. Configure where credentials are sent:
   • HTTP Headers (recommended)
   • Query Parameters
   • Custom expression
6. Save the policy — it applies immediately with no redeployment needed

Configuring Credential Location

You decide where the client sends credentials. The most common patterns:

Pattern 1: HTTP Headers (Standard)

Policy Configuration:
  Client ID Expression:     #[attributes.headers.'client_id']
  Client Secret Expression: #[attributes.headers.'client_secret']

Client sends:
  GET /orders
  client_id: a1b2c3d4
  client_secret: z9y8x7w6

Pattern 2: Authorization Header (Basic Auth style)

Policy Configuration:
  Client ID Expression:     #[attributes.headers.'Authorization' 
                               splitBy ' '[1] 
                               |> fromBase64($) 
                               |> splitBy ':')[0]]
  Client Secret Expression: (similar for the secret part)

Client sends:
  Authorization: Basic YTFiMmMzZDQ6ejl5OHg3dzY=
  (base64 of "client_id:client_secret")

Pattern 3: Query Parameters (for simple integrations)

Policy Configuration:
  Client ID Expression:     #[attributes.queryParams.'client_id']
  Client Secret Expression: #[attributes.queryParams.'client_secret']

Client sends:
  GET /orders?client_id=a1b2c3d4&client_secret=z9y8x7w6
  (avoid this in production — credentials visible in browser history and logs)

Application Registration in Anypoint Exchange

API consumers register their applications through Anypoint Exchange. The registration process generates the Client ID and Secret pair.

Registration Process:
  1. Consumer developer goes to Anypoint Exchange
  2. Finds the API they want to use
  3. Clicks "Request Access"
  4. Creates an application:
     App Name:    "Mobile Order App"
     Description: "iOS application for placing orders"
  5. Selects the API tier (if SLA tiers are configured)
  6. Submits request
  7. API owner approves (manual) or auto-approved
  8. Consumer receives:
     Client ID:     f7e8d9c0b1a2
     Client Secret: q3r4s5t6u7v8

Revoking Client Access

If a client application is compromised, behaving badly, or no longer authorized, revoke its access immediately in API Manager without touching your application code.

Revocation Steps:
  1. Open API Manager → Clients
  2. Find the client application
  3. Click "Revoke" or change status to "Inactive"
  4. Policy rejects all requests from this client_id immediately

Effect:
  Before revocation: client_id "a1b2c3d4" → 200 OK ✓
  After revocation:  client_id "a1b2c3d4" → 401 Unauthorized ✗
  Other clients:     unaffected ✓

Combining Client ID Enforcement with Other Policies

Client ID Enforcement works well as the first layer of a policy stack. Add rate limiting on top to prevent any single client from overwhelming the API.

Policy Stack Example

Incoming Request
    │
    ▼ Policy Order:
[1. Client ID Enforcement]   ← Is this a registered client?
    │ (passes)
    ▼
[2. Rate Limiting: 100/min per client_id]  ← Is this client within its limit?
    │ (passes)
    ▼
[3. JSON Threat Protection]  ← Is the payload safe?
    │ (passes)
    ▼
[Mule Application]

Client ID in Flow Variables

Once Client ID Enforcement passes, the client ID is available inside your Mule flow as a header attribute. Use it for logging, personalization, or routing different clients to different backend logic.

Inside your Mule flow after Client ID Enforcement:
  attributes.headers.'client_id' = "f7e8d9c0b1a2"

Uses:
[Logger: "Request from client: #[attributes.headers.'client_id']"]

[Database: SELECT tier FROM client_registry 
           WHERE client_id = '#[attributes.headers.'client_id']']

[Choice Router: route premium clients to faster backend]
  When: vars.clientTier == "premium"
    → [HTTP Request: premium-backend-api/orders]
  Default:
    → [HTTP Request: standard-backend-api/orders]