Delegation chain explorer

An enterprise identity provider brokers the token

The same agent host and tasks server, with the company's identity provider deciding who may use which MCP server. The host signs Alex in at the identity provider, exchanges the ID token for an Identity Assertion JWT Authorization Grant (ID-JAG) addressed to the server's authorization server, and presents that grant for an access token. No consent screen at the tasks server: the policy lives at the identity provider.

The chain, step by step

AlexUser
Agent hostMCP client
Enterprise IdP (idp.corp.example)Identity provider
auth.tasks.exampleAuthorization server
Tasks MCP serverMCP server
  1. Step 1: Alex to Enterprise IdP (idp.corp.example)

    Alex signs in to the agent host with the company's single sign-on

    The host is an application the enterprise manages. The identity provider authenticates Alex and issues the host an ID token it keeps for later.

    4.2. User AuthenticationIdentity Assertion JWT Authorization Grant draft-04

  2. Step 2: Enterprise IdP (idp.corp.example) to Agent host

    ID token for the agent host

    4.2. User AuthenticationIdentity Assertion JWT Authorization Grant draft-04

    ID tokentyp JWT · alg RS256 · kid idp-2026

    iss
    https://idp.corp.example
    sub
    u-48213
    aud
    agent-host
    email
    alex@corp.example
    exp
    1790000000
    iat
    1789996400

    Unchanged since the previous token in this chain.

  3. Step 3: Agent host to Tasks MCP server

    Unauthenticated request, challenge, protected resource metadata and authorization server metadata, as in the baseline chain

    Discovery is unchanged: the host learns the server's resource identifier and that auth.tasks.example is its authorization server, and the server declares the enterprise-managed authorization extension.

    Implementation guide › For MCP serversMCP Enterprise-Managed Authorization stable

  4. Step 4: Agent host to Enterprise IdP (idp.corp.example)

    POST /token: grant_type=token-exchange, subject_token=<ID token>, subject_token_type=id_token, requested_token_type=id-jag, audience=https://auth.tasks.example, resource=https://mcp.tasks.example/mcp, scope=tasks:read

    Instead of sending Alex to the tasks server's authorization endpoint, the host asks the identity provider for a grant it can present there. The audience is the resource authorization server, not the MCP server.

    4.3. Token ExchangeIdentity Assertion JWT Authorization Grant draft-04

  5. Step 5: Enterprise IdP (idp.corp.example) to itself

    Evaluate policy: may this user, through this app, reach this server with this scope?

    Group membership, the approved-app list and conditional access are checked here, once, centrally. A user without access gets an error and the host never receives a grant.

    4.3.3. Processing RulesIdentity Assertion JWT Authorization Grant draft-04

  6. Step 6: Enterprise IdP (idp.corp.example) to Agent host

    issued_token_type=id-jag with the signed grant

    4.3.4. ResponseIdentity Assertion JWT Authorization Grant draft-04

    Identity Assertion JWT Authorization Granttyp oauth-id-jag+jwt · alg RS256 · kid idp-2026

    iss
    https://idp.corp.example
    sub
    u-48213
    audchanged
    https://auth.tasks.example
    client_idadded
    https://agent.example/client.json
    scopeadded
    tasks:read
    resourceadded
    https://mcp.tasks.example/mcp
    jtiadded
    3a9e
    expchanged
    1789996700
    iat
    1789996400
    emailremoved
    no longer in the token

    7 claims differ from the previous token in this chain. The required claims are iss, sub, aud, client_id, jti, exp and iat; scope and resource are optional and carry what the policy allowed.

  7. Step 7: Agent host to auth.tasks.example

    POST /token: grant_type=jwt-bearer, assertion=<ID-JAG>, client authentication

    The grant is presented as an assertion; the host authenticates with the credentials it holds at this authorization server.

    4.4. Access Token RequestIdentity Assertion JWT Authorization Grant draft-04

  8. Step 8: auth.tasks.example to itself

    Validate the grant: signature against the IdP's keys, iss is a trusted IdP, aud is this server, exp, jti unused; map sub to an account

    The authorization server trusts the identity provider's decision and issues no consent screen of its own.

    4.4.1. Processing RulesIdentity Assertion JWT Authorization Grant draft-04

  9. Step 9: auth.tasks.example to Agent host

    Access token for the tasks server, scope as granted

    4.4.2. ResponseIdentity Assertion JWT Authorization Grant draft-04

    Access token for the Tasks MCP servertyp at+jwt · alg ES256 · kid auth-2026-1

    isschanged
    https://auth.tasks.example
    subchanged
    alex
    audchanged
    https://mcp.tasks.example/mcp
    client_id
    https://agent.example/client.json
    scope
    tasks:read
    expchanged
    1790000000
    iatchanged
    1789996800
    jtichanged
    d02f
    resourceremoved
    no longer in the token

    7 claims differ from the previous token in this chain.

  10. Step 10: Agent host to Tasks MCP server

    POST /mcp (tools/call) with Authorization: Bearer <access token>

    Authorization › Access Token UsageMCP Authorization 2026-07-28

    Access token as presentedtyp at+jwt · alg ES256 · kid auth-2026-1

    iss
    https://auth.tasks.example
    sub
    alex
    aud
    https://mcp.tasks.example/mcp
    client_id
    https://agent.example/client.json
    scope
    tasks:read
    exp
    1790000000
    iat
    1789996800
    jti
    d02f

    Unchanged since the previous token in this chain.

  11. Step 11: Tasks MCP server to itself

    Validate signature, iss, exp and that aud is this server; check scope

    Security Considerations › Token Audience Binding and ValidationMCP Authorization 2026-07-28

Requirements this chain exercises