Flex / Omni Gateway: Credential Injection OAuth 2.0 vs. OAuth 2.0 OBO Credential Injection — Which Outbound Policy to Use and Supported Grant Types

CAUSE

Flex/Omni Gateway ships TWO distinct outbound Security policies, and they do different things (see the Outbound Policies Directory, https://docs.mulesoft.com/gateway/1.13/policies-outbound-directory):

- "Credential Injection OAuth 2.0" — fetches a token from an OAuth 2.0 token endpoint using the policy's OWN configured credentials and injects it as an Authorization header. It does NOT exchange the caller's incoming token, so it cannot produce a user-delegated ("on behalf of") token.

- "OAuth 2.0 OBO Credential Injection" — EXCHANGES the incoming bearer token for a backend-scoped token using OAuth 2.0 Token Exchange (RFC 8693), Microsoft Entra ID On-Behalf-Of, or OAuth 2.0 Token Exchange with CIBA. This is the policy that produces the user-delegated token the backend requires.

An "OBO_TOKEN_MISSING" / "backend-scoped JWT required for user-delegated access" error therefore means the outbound path is not performing the token exchange — either the OBO Credential Injection policy is not applied to the outbound service, or it is misconfigured, or (a common trap) the plain "Credential Injection OAuth 2.0" policy was applied instead of the OBO one.

Supported grant types for "Credential Injection OAuth 2.0" (https://docs.mulesoft.com/gateway/1.13/policies-outbound-oauth):
  grantType is REQUIRED and supports ONLY: clientCredentials or password
It does NOT support the JWT Bearer grant type (RFC 7523 / urn:ietf:params:oauth:grant-type:jwt-bearer). If you need a delegated / token-exchange flow, use the OBO policy, not this one. (First available: Flex/Omni Gateway v1.9.0.)

SOLUTION

1. Confirm which policy the flow needs:
   - Need a fixed service token from your own client credentials → "Credential Injection OAuth 2.0" (grantType clientCredentials or password).
   - Need to exchange the caller's token for a backend/user-delegated token → "OAuth 2.0 OBO Credential Injection".

2. Apply and configure the OBO Credential Injection policy on the OUTBOUND service (with a JWT/token validation policy inbound so the caller's token is present). Key parameters (https://docs.mulesoft.com/gateway/1.13/policies-outbound-oauth-obo):
     - Token Exchange Flow: "OAuth 2.0 Token Exchange" (RFC 8693) or "Microsoft Entra ID On-Behalf-Of".
     - Client ID / Client Secret: the OAuth 2.0 client credentials used for the exchange (e.g. the client configured on your Okta / Entra authorization server).
     - Token Endpoint: the authorization server's token endpoint URL.
     - Target Type (REQUIRED for the RFC 8693 flow): "Audience" (logical identifier of the target service, default) or "Resource" (physical URI, RFC 8707).
     - Target Value (REQUIRED for the RFC 8693 flow): the audience URI or resource URI the exchanged token should be scoped to (this is what makes the token "backend-scoped").
     - Subject Token Type: defaults to urn:ietf:params:oauth:token-type:access_token (the incoming Authorization bearer token); adjust only if the subject token differs.

3. Operational constraints to verify:
   - The OAuth 2.0 OBO Credential Injection policy is NOT supported in Local Mode — use a Connected/managed gateway.
   - For a multi-replica or managed gateway, enable DISTRIBUTED token caching so exchanged tokens are shared across replicas (by default the token cache is per-replica).

4. Validate on the authorization server: the exchange client must be permitted to perform token exchange to the target audience/resource, and the returned token must carry the scope/audience the backend enforces. Re-test the failing tool call; the "OBO_TOKEN_MISSING" error should clear once a backend-scoped token is injected.