Okta, Auth0, and Descope ship Cross App Access (ID-JAG) within eight days
Between August 24 and September 1, 2026, Okta, Auth0, and Descope each shipped support for Cross App Access, the pattern built on the IETF ID-JAG draft that lets an enterprise IdP decide which apps an AI agent may reach.
What happened
Three identity vendors shipped support for Cross App Access (XAA) inside eight days, according to WorkOS's analysis:
- August 24, 2026: Okta. Agent SSO reached general availability. Okta's Oktane press release on September 22, 2026 describes it as exchanging non-expiring keys for short-lived, identity-governed tokens.
- August 31, 2026: Auth0. The requesting-app half of XAA moved to early access, running on Auth0 Token Vault over ID-JAG. The resource-app side was already in early access. It is available on the Enterprise, B2B Pro, and B2B Essential plans.
- September 1, 2026: Descope. Descope announced both ID-JAG validation and issuance in its Agentic Identity Hub. Tenant admins can configure XAA themselves.
All three implement the same IETF OAuth Working Group draft, the Identity Assertion JWT Authorization Grant (ID-JAG), currently at draft-04 from May 21, 2026. The Model Context Protocol publishes the same pattern as its optional Enterprise-Managed Authorization extension.
Why it matters
Until now, an AI agent reached a business app through per-user OAuth consent. Each employee clicked "allow," and IT had no central view of which agent could touch which system. ID-JAG moves that decision into the company's identity provider. The IdP mints an assertion only when admin policy allows that app to reach that resource for that user.
Convergence is the news. One vendor shipping a draft is an experiment. Three shipping the same draft in eight days means B2B SaaS buyers will start asking for it in security reviews.
Deepak's take
Agent access is following the path workforce SSO took a decade ago. First every app had its own login, then IT demanded one place to grant and revoke access. Per-user OAuth consent for agents is the per-app password of this cycle, and enterprise buyers will not tolerate it for long.
The part most teams will miss is that the hard work is on the resource side. If you sell SaaS to enterprises, your authorization server needs to accept ID-JAGs from your customers' IdPs and map each one to the right tenant and user. That is a tenancy and account-linking problem, not a checkbox. Teams that already run clean multi-tenant SSO will find it straightforward. Teams that bolted SSO on late will find out where the gaps are.
Still a draft, though. The ID-JAG spec can change before it becomes an RFC, and early access is not general availability. Build behind a feature flag and track the draft revisions.
What to do
- B2B SaaS teams selling to enterprises: Decide whether your app will be a resource app (agents call your API) or a requesting app (your agent calls others), or both. Resource-app support means accepting RFC 7523 jwt-bearer grants and advertising jwt-bearer in grant_types_supported in your authorization server metadata.
- Teams on Auth0 or Descope: Check your plan and tenant settings for XAA early-access availability before building your own validation. See the Auth0 and Descope profiles.
- Teams running MCP servers: Support Client ID Metadata Documents first; the client_id inside an ID-JAG is a CIMD identifier. Remember the MCP extension is opt-in on both sides.
- Everyone: Read the enterprise-managed authorization guide for the full build, and AI agents don't have passwords for why agents need their own identity model.