v2025.11.7

  • 2 minute(s) read
Prev Next

Released on 2025.11.20

New Feature: Token Delegation Support

This release has added support for token delegation via OAuth 2.0 token exchange grant types. This feature enables secure, on-behalf-of authentication flows that allow services to delegate access tokens to downstream clients while maintaining a clear audit trail of the delegation chain.

What's New

Token Exchange (On-Behalf-Of) Flow w/token delegation

  • Exchange an existing access token for a new token representing a delegated identity

  • Supports the standard OAuth 2.0 token exchange grant type (urn:ietf:params:oauth:grant-type:token-exchange)

  • Delegated tokens include an act (actor) claim that preserves the original client identity

Chained Delegation

  • Support for multi-level token delegation

  • Each delegation level is preserved in nested act claims within the JWT

  • Enables complex service-to-service authentication scenarios

Benefits

  • Enhanced Security: Maintain clear identity chains through service layers

  • Observability: Track the original requesting client through the act claim in delegated tokens

  • Standards Compliant: Implements RFC 8693 (OAuth 2.0 Token Exchange) for interoperability

How It Works

  1. Initial Token: Obtain an access token using the client credentials grant

  2. Token Exchange: Exchange the initial token for a delegated token using the token exchange grant type

  3. Chained Delegation (Optional): Perform additional token exchanges to create multi-level delegation chains

Technical Details

  • Grant Type: urn:ietf:params:oauth:grant-type:token-exchange

  • Token Type: access_token

  • JWT Claims: Delegated tokens include an act claim containing the original client's sub (subject) identifier

  • Endpoint: (example) POST https://maverics.sonarsystems.com/oauth2/token

For detailed implementation steps and examples, see the Token Delegation Flow: Step-by-Step Guide.

Use Cases

  • AI Agents and MCP Bridge: AI agents access enterprise APIs through MCP tools that proxy requests via the Maverics AI Identity Gateway. Each tool invocation triggers a token exchange—the MCP server requests a delegated token from the gateway, which returns a short-lived access token with the agent runner's identity in the act claim. The gateway enforces OPA/Rego policies at runtime before proxying to downstream APIs, ensuring every agent action is authenticated, authorized against the actual end-user identity, and fully audited. Developers get frictionless API access through standard MCP tools; architects get centralized policy enforcement and complete visibility into what agents do and on whose behalf.

  • API gateways delegating to backend services: API gateways can exchange tokens on behalf of clients, allowing backend services to see both the gateway identity and the original client identity in the act claim for proper authorization decisions

Decoded JWT Examples (Each Hop)

Below are decoded payloads that illustrate how the act claim carries the delegation chain across hops.

Hop 1: Original client (client-frontend)

{
  "iss": "https://auth.example.com",
  "sub": "client-frontend",
  "aud": "orchestrator-api",
  "scope": "orders:read",
  "iat": 1714580000,
  "exp": 1714583600
}

Hop 2: Gateway exchanges on behalf of frontend

{
  "iss": "https://auth.example.com",
  "sub": "api-gateway",
  "aud": "orders-service",
  "scope": "orders:read",
  "act": {
    "sub": "client-frontend"
  },
  "iat": 1714580050,
  "exp": 1714583650
}

Hop 3: Orders service exchanges on behalf of gateway

{
  "iss": "https://auth.example.com",
  "sub": "orders-service",
  "aud": "payments-service",
  "scope": "payments:charge",
  "act": {
    "sub": "api-gateway",
    "act": {
      "sub": "client-frontend"
    }
  },
  "iat": 1714580100,
  "exp": 1714583700
}

Learn More: OIDC, MCP Bridge

Related articles