← Back

Cross App Access (XAA)

🧪 Enterprise IdP simulated

Auth0's Early Access implementation of the Identity Assertion Authorization Grant — Agent0 (Requesting App) redeems a short-lived, IT-policy-gated ID-JAG for a Todo0 (Resource App) access token via a jwt-bearer grant, with no consent screen. This demo simulates the Enterprise IdP locally with a small jose-signed OIDC-shaped issuer, federated into the shared tenant used by every other demo in this suite — the Requesting App, Resource App, and access token are all real Auth0.

Architecture & Token Flow

🧪 Simulated locally

Enterprise IdP

Issues ID-JAG, policy-gated

Agent0

Requesting App

Real Auth0 tenant

Todo0

Resource App

1Agent0 already holds an ID token (SSO login is covered elsewhere in this suite).
2Agent0 exchanges the ID token for a short-lived ID-JAG at the Enterprise IdP.
3Agent0 presents the ID-JAG to Todo0's real Auth0 tenant: POST /oauth/token, grant_type=jwt-bearer.
4Agent0 calls Todo0's API with the resulting Bearer access token — no consent screen.
With XAA vs Without

With Cross App Access

  1. Employee asks Agent0 to do something that needs Todo0 data
  2. Agent0 exchanges its ID token for an ID-JAG at the enterprise IdP (policy-gated)
  3. Agent0 presents the ID-JAG to Todo0's Auth0 tenant for an access token
  4. Agent0 calls Todo0's API with the access token — no consent screen, ever

Traditional OAuth, every time

  1. Employee asks Agent0 to do something that needs Todo0 data
  2. Agent0 redirects the employee to Todo0 for an OAuth consent screen
  3. Employee reviews and approves the requested scopes — every time, or Agent0 falls back to a long-lived shared credential instead
  4. Agent0 calls Todo0's API with the resulting token
1. ID token held
→2. ID-JAG issued
→3. Access token (Auth0)
→4. API called

IT admin: XAA policy for Agent0 → Todo0

Enforced server-side at the mock IdP's ID-JAG mint call — revoking here blocks the very next exchange, before an ID-JAG is ever issued.

Step 1: Agent0 already holds an ID token

xaa.demo@atko.email already completed enterprise SSO into Agent0 (the Requesting App) — that login flow is covered elsewhere in this suite (Traditional/BFF demos). This mock Enterprise IdP mints the ID token that login would have produced.

Sources

Auth0 blog: Cross App Access for AI agents

API reference: Cross App Access get-token

Docs: Cross App Access for AI agents / MCP

Security Implications

Strengths

  • Agent0 never holds a standing credential for Todo0 — it presents a short-lived (~60s) ID-JAG and receives a scoped access token per exchange, not a long-lived shared secret to the target API.
  • Governance is centralized at the Enterprise IdP: an admin-defined XAA policy gates ID-JAG issuance, so revoking access for Agent0 takes effect at the moment of the next exchange — not by hunting down and disabling it individually in every downstream Resource App.
  • No consent-prompt fatigue: the end user never sees a redirect or an OAuth consent screen for the agent-to-app call at all — the trust decision was made once, centrally, by IT admin policy, not per-request by the user clicking "allow".
  • Todo0 (Resource App) is genuinely real Auth0 (Early Access) on the same shared tenant every other demo in this suite uses — only the Enterprise IdP is simulated, so its config, its API validation, and (once Auth0 ships Requesting App support) the access token itself are exactly what a real deployment produces.

Risks & Considerations

  • As of writing, Auth0 only supports the Resource App side of Cross App Access — Requesting App redemption (the actual /oauth/token jwt-bearer exchange) isn't live, so this demo always attempts the real call first, then falls back to a clearly-labeled mock access token. The UI badges which one occurred; treat any screenshot or recording of this demo as showing the mock leg until that badge flips.
  • This demo's Enterprise IdP is a small locally-hosted mock, federated into the tenant via a custom OIDC connection — a real deployment federates an actual enterprise IdP (e.g. Okta), which is a separately-managed trust relationship an attacker would need to compromise, not something this demo exercises.
  • Auth0's real Cross App Access explicitly disables dynamic user creation on ID-JAG redemption — a `sub` that hasn't previously authenticated to the Resource App via the federated connection fails with "User not found", not a silent JIT provision. This demo works around it with one fixed, pre-provisioned identity rather than a free-text field.
  • There are two independent enforcement points, not one: the mock IdP's policy gate (before an ID-JAG is minted) and Auth0's own real EA dashboard policy (at the actual /oauth/token redemption). Getting only one of them right leaves the other as the sole remaining boundary.
  • A leaked ID-JAG is a bearer credential for the named user for its entire (short) validity window, exactly like a leaked access token — short expiry narrows the window, it doesn't change the bearer-token risk model.

Hardening Checklist

  • Keep ID-JAG lifetimes as short as workable (this demo uses 60s) — it's a bearer assertion, and short expiry is the primary control against replay.
  • Enforce the client_id/client_secret + registered-client check on every /oauth/token redemption — never accept an ID-JAG from a Requesting App that isn't explicitly provisioned for that specific Resource App.
  • Treat the admin-defined XAA policy as the real authorization boundary, not the demo UI — verify a policy revocation is enforced at the IdP's token-minting call itself, and separately confirm Auth0's own dashboard policy actually blocks redemption too.