Skip to content
Agent Identity

Deployment pattern

All patterns

Cross-domain chaining

UserAS AAgent in AAS BAPI in B

Cross-domain identity chaining

/patterns/cross-domain-chaining

The grant starts at AS A and must be accepted at AS B in another organization. Identity chaining (I-D) composes RFC 8693 and RFC 7523. RFC 9207 mix-up defenses exist because two issuers are now in play.

When you see it

An agent reads mail in the company tenant and files a ticket in a vendor SaaS whose AS is not yours. Partner integrations where each side has its own authorization server. Distinct from XAA only in that XAA is the IdP-brokered profile of a similar grant; this row is the general two-AS chain.

Actors and trust

  • Client in domain AAgent instance

    Holds a token from AS A. Must not present it at API C in domain B.

  • AS AOther

    Token-exchanges a JWT authorization grant audience-restricted to AS B.

  • AS BOther

    Redeems that JWT via RFC 7523 and issues an access token for its own resource. Must not be mixed up with AS A.

  • Resource in domain BResource

    Accepts only tokens from AS B, aud = itself.

Topology

UserAS AAgent in AAS BAPI in B
  • UserOriginal delegation →AS A
  • Agent in ARFC 8693 exchange → JWT grant, aud = AS B →AS A
  • Agent in ARFC 7523 JWT bearer grant (iss checks / RFC 9207) →AS B
  • AS BAccess token for API C →Agent in A
  • Agent in ACall in domain B →API in B
Two ASes, two audiences. The client exchanges at A for a grant B will redeem. Mix-up defenses are mandatory.

Primary

Optional

Do not use

  • Transaction Tokens

    Same-domain context propagation, not a cross-AS grant.

  • Presenting AS A's access token at API C

    Wrong audience, wrong issuer, classic confused deputy.

  • A private cross-domain token format

    The chaining I-D exists so you do not invent one.

Why these, and not those

Two authorization servers means identity chaining, not a private JWT format and not a transaction token (txn-tokens are same-domain). RFC 8693 produces the grant; RFC 7523 is how B consumes a JWT assertion; the chaining I-D writes that down as a profile (RFC Editor queue as of July 2026 — no RFC number yet). RFC 9207 iss in the authorization response, plus exact issuer metadata checks, are how you stop mix-up when the client talks to more than one AS. XAA is the IdP-shaped variant; FAPI if B is high-risk.

Related flows

Sequence diagrams, not this topology cut. All flows

Back to the matrix