JWT, OIDC and on-behalf-of — auth flows in Istio Ambient

🔁 OIDC + token exchange Solo Enterprise

Enterprise Upstream OSS Istio doesn't run an OIDC login flow at the gateway — you bolt one on with ext-authz, oauth2-proxy or a custom filter. Solo Enterprise / agentgateway ships it as a first-class AuthConfig with PKCE + session cookie support (Keycloak, Entra ID, Okta) and a built-in Security Token Service that does RFC 8693 token exchange. The YAML below is verbatim from the docs at docs.solo.io/agentgateway/.../oauth/authorization-code and .../obo/impersonation.

apiVersion: extauth.solo.io/v1
kind: AuthConfig
metadata:
  name: oauth-authorization-code
  namespace: agentgateway-system
spec:
  configs:
  - oauth2:
      oidcAuthorizationCode:
        appUrl: "http://${INGRESS_GW_ADDRESS}:80"
        callbackPath: /openai
        clientId: ${KEYCLOAK_CLIENT}
        clientSecretRef:
          name: oauth-keycloak
          namespace: agentgateway-system
        issuerUrl: "${KEYCLOAK_URL}/realms/master/"
        scopes:
        - email
        session:
          failOnFetchFailure: true
          redis:
            cookieName: keycloak-session
            options:
              host: :6379
        headers:
          idTokenHeader: jwt          # forward id_token as Authorization upstream
---
apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: oauth-authorization-code
  namespace: agentgateway-system
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: agentgateway-proxy
  traffic:
    entExtAuth:
      authConfigRef:
        name: oauth-authorization-code
        namespace: agentgateway-system
      backendRef:
        name: ext-auth-service-enterprise-agentgateway
        namespace: agentgateway-system
        port: 8083

# Two things wire the exchange:
#   1. A Secret carrying the downstream IdP's client credentials and token URL
#   2. A policy that references that Secret via tokenExchange.elicitation.secretName
#
# The gateway's STS reads the Secret, then on each request it swaps the
# inbound user token for a downstream-scoped token before forwarding.
apiVersion: v1
kind: Secret
metadata:
  name: mcp-backend-token-exchange
  namespace: agentgateway-system
type: Opaque
stringData:
  app_id: mcp-backend
  client_id: "<downstream-oauth-client-id>"
  client_secret: "<downstream-oauth-client-secret>"
  authorize_url: "https://idp.example.com/oauth/authorize"
  access_token_url: "https://idp.example.com/oauth/token"
  scopes: "mcp.read mcp.write offline_access"
---
apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: impersonation
  namespace: agentgateway-system
spec:
  targetRefs:
  - kind: AgentgatewayBackend
    group: agentgateway.dev
    name: mcp-backend
  backend:
    tokenExchange:
      elicitation:
        secretName: mcp-backend-token-exchange   # carries the IdP client + token URL
---
# Microsoft Entra ID variant — same idea, but Entra needs the
# tenant/client wired explicitly instead of via the elicitation Secret.
apiVersion: enterpriseagentgateway.solo.io/v1alpha1
kind: EnterpriseAgentgatewayPolicy
metadata:
  name: impersonation-entra
  namespace: agentgateway-system
spec:
  targetRefs:
  - kind: AgentgatewayBackend
    group: agentgateway.dev
    name: graph-mcp-backend
  backend:
    tokenExchange:
      entra:
        tenantId: "<entra-tenant-uuid>"
        clientId: "<gateway-app-client-id>"
        clientSecretRef:
          name: entra-client-secret
          key: client_secret
        scope: "https://graph.microsoft.com/.default"
---
# The exchange request the STS makes on the wire (you don't write this
# yourself — it's what the gateway sends to access_token_url):
#
#   POST /oauth/token
#   grant_type        = urn:ietf:params:oauth:grant-type:token-exchange   # RFC 8693
#                       (or urn:...:grant-type:jwt-bearer for Entra OBO)
#   subject_token     = <user JWT from corporate IdP>
#   subject_token_type= urn:ietf:params:oauth:token-type:jwt
#   requested_token_type = urn:ietf:params:oauth:token-type:access_token
#   audience          = mcp-backend

# The chart only exposes two knobs. Everything else (which IdP, which
# scopes, which audience) is per-policy via the CRD above. The default
# secretName here is the cluster-wide default used when a policy's
# elicitation block omits its own secretName.

tokenExchange:
  enabled: true                       # required to start the exchange webserver
  elicitation:
    secretName: mcp-backend-token-exchange   # default IdP credential Secret

What's in the swapped token — and what NOT to do

Both OBO modes produce a per-user, per-request token — sub is always the user. The difference is whether the agent's identity is also carried via act. The third card is the shape OBO is designed to replace: one shared service-account token for every call, with user identity lost (or relegated to a header). Don't ship that.

{
  "iss": "solo-sts",
  "sub": "alice@corp.com",
  "aud": "snowflake-mcp",
  "exp": 1700003600
}

{
  "iss": "solo-sts",
  "sub": "alice@corp.com",
  "act": {
    "sub": "spiffe://.../mcp-agent"
  },
  "aud": "snowflake-mcp",
  "exp": 1700003600
}

{
  "iss": "solo-sts",
  "sub": "agentgateway-sa",
  "aud": "snowflake-mcp",
  "exp": 1700003600
}

// + header: x-on-behalf-of: alice@corp.com
// (or worse — no user context at all)

Note on naming: which CRD you reach for depends on the gateway. On agentgateway, JWT validation and ext-auth attach via EnterpriseAgentgatewayPolicy.spec.traffic.jwtAuthentication and .traffic.extAuth. On kgateway, the same building blocks attach via EnterpriseKgatewayTrafficPolicy.spec.entJWT and .spec.entExtAuth, with the OAuth recipe in a separate AuthConfig. The upstream Istio RequestAuthentication still works on a waypoint; the Solo CRDs add policy attachment, multi-tenant routing and the STS integration.

6.6 · STS Wrong subject_token type

The STS only accepts the urn:ietf:params:oauth:token-type:jwt or access_token token types. An unrecognised value is rejected at the token endpoint before any claim is examined.

$ curl -is -X POST https://gw.example.com/oauth/token \
    -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
    -d subject_token=$VALID_READONLY_JWT \
    -d subject_token_type=urn:wrong:type \
    -d audience=api.example.com | head -8
HTTP/1.1 400 Bad Request
content-type: application/json

{"error":"invalid_request",
 "error_description":"unsupported subject_token_type"}

6.7 · STS Audience the client cannot request

The subject token is valid, but the request asks the STS to mint a token for an audience the calling client is not registered to obtain tokens for. The STS refuses to widen.

$ curl -is -X POST https://gw.example.com/oauth/token \
    -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
    -d subject_token=$VALID_READONLY_JWT \
    -d subject_token_type=urn:ietf:params:oauth:token-type:jwt \
    -d audience=api.different-tenant.com | head -8
HTTP/1.1 403 Forbidden
content-type: application/json

{"error":"invalid_target",
 "error_description":"audience not permitted for this client"}

The STS is the audience gatekeeper, not the upstream. A successful exchange would have returned a JWT whose aud claim was attacker-chosen.

6.8 · STS Downscoping is one-way

The inbound subject token carries scope=invoke.orchestrator. The exchange request asks for the superset scope="invoke.planner admin.planner". The STS returns either narrower-or-equivalent scope or rejects.

$ curl -s -X POST https://gw.example.com/oauth/token \
    -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
    -d subject_token=$VALID_READONLY_JWT \
    -d subject_token_type=urn:ietf:params:oauth:token-type:jwt \
    -d scope="invoke.planner admin.planner" \
    -d audience=planner | jq -r '.scope // .error_description'

invoke.planner

Confirms the chain of actors cannot escalate. The exchanged token's act claim records who performed the exchange, so audit logs preserve the original subject and the actor that called the STS.

6.9 · Upstream Blind pass-through is rejected

Skip the exchange. Forward $VALID_READONLY_JWT (whose aud=api.example.com) directly to a downstream MCP server whose RequestAuthentication.audiences=["mcp.upstream"]. The upstream rejects on aud mismatch.

$ curl -is -H "Authorization: Bearer $VALID_READONLY_JWT" \
    http://mcp.upstream.example.com/tools | head -4
HTTP/1.1 403 Forbidden
www-authenticate: Bearer realm="http", error="invalid_token"
content-length: 32

Audiences in Jwt are not allowed

Evidence that the exchange is not optional: the only way a request reaches the upstream with valid auth is by going through the STS so the gateway swaps the token for one whose aud matches the upstream.

6.10 · Upstream No act claim where one is required

The upstream's CEL policy requires request.auth.claims["act"]["sub"] == "planner". Present an STS-minted token that has no act claim (i.e. it was issued by a flow that skipped a hop). The CEL expression evaluates falsy and the policy denies.

# Exchange directly without a prior hop, omitting an actor_token
$ HOP_TOKEN=$(curl -s -X POST https://gw.example.com/oauth/token \
    -d grant_type=urn:ietf:params:oauth:grant-type:token-exchange \
    -d subject_token=$VALID_READONLY_JWT \
    -d subject_token_type=urn:ietf:params:oauth:token-type:jwt \
    -d audience=tool-mcp | jq -r .access_token)

$ curl -is -H "Authorization: Bearer $HOP_TOKEN" \
    http://tool-mcp.example.com/mcp | head -3
HTTP/1.1 403 Forbidden
content-length: 19

RBAC: access denied