Cross-domain access is everywhere in today's software landscape. Whether you look at enterprise SaaS applications, AI agents interacting with user data across multiple platforms, or "integrated experiences" pulling information from a calendar, a chat tool, and a wiki—everything eventually needs to talk across boundaries.
Development teams frequently reach for the quickest path to wire these systems together. Usually, teams fall back on two "obvious" architectural shortcuts. However, as experience deploying these architectures at scale demonstrates, both models break down in production.
Let's take a closer look at why these shortcuts fail and what a resilient cross-domain pattern actually looks like.
🧶 Shortcut #1: Have the IdP issue the access token directly
The pattern: the client takes its ID Token to the IdP, exchanges it for an access token, and sends that access token straight to the resource app's API.
Why it's tempting: it reuses the IdP that everyone already trusts. It feels like a clean, one-stop shop.
Why it breaks: every API on the receiving end now has to trust a growing list of foreign token issuers — each with its own quirks around token format, claim conventions, key rotation, and revocation.
Suddenly your API team is in the federation business, doing one-off integrations per IdP. That's not a sustainable model for building APIs at scale. APIs are far better served by having a local authorization server issuing the tokens they validate — one issuer, one model, one set of rules.
🪪 Shortcut #2: Send the ID Token across domains
The pattern: skip the IdP-issued access token and present the original ID Token directly at the receiving app's authorization server, exchanging it for a locally issued access token.
Why it's tempting: ID Tokens are standardized, so it feels like it sidesteps the trust-fan-out problem from #1.
Why it breaks: ID Tokens are issued for one audience — the application the user signed into. Sending them somewhere else violates that audience binding, opens up replay and misuse risks.
🎯 What Cross-App Access does differently
Cross-App Access (XAA) uses a two-stage flow — and each stage exists specifically to fix one of the problems above.
Stage 1: The client makes a Token Exchange request to the IdP to exchange the ID Token for an ID-JAG: a purpose-built, short-lived, audience-bound grant for the resource authorization server.
No ID Token misuse, no audience confusion. The IdP also stays in the loop to govern whether this cross-app access should happen at all — exactly where enterprise IT already manages who can access what.
Stage 2: The resource app's authorization server exchanges the ID-JAG for its own access token. The API keeps its local AS, its own token format, and its own revocation story. It only has to trust the access tokens issued by its own AS — not a foreign access token.
We can push all the complexity of user login, token minting, and cross-domain policy evaluation onto the specialized identity components, keeping the resource API free to do the much simpler task of validating its own domain's access tokens and serving data.
If you're designing cross-domain access for an AI agent, an enterprise suite, or any multi-vendor ecosystem, this is the pattern to follow. The IETF draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/
