Table of Contents
To do their jobs properly, enterprise applications need to talk to each other: project management tools pull data from CRMs, a CI/CD pipeline pushes to a code repository, an analytics dashboard queries multiple SaaS APIs.
These connections have traditionally relied on one of two approaches:
Long-lived API keys that never expire, or
OAuth flows that require manual user approval for every integration
Both scale poorly, which is why the Identity Assertion JWT Authorization Grant (ID-JAG) is gaining traction—and seeing adoption for agentic AI use cases.
In simplest terms, ID-JAG extends enterprise SSO to APIs. Just as your identity provider (IdP) manages who can log in to which applications, ID-JAG lets that same IdP manage which applications can access other applications’ APIs on behalf of users.
Note that you’ll often see this specification referred to as “XAA,” or “Cross-App Access.” That’s Okta’s branding for their implementation of the underlying ID-JAG standard, but we’ll be treating the two terms as interchangeable.
In the following post, we’ll walk through the problem that XAA/ID-JAG solves, how it works, its proposed use cases, and what you can do to prepare for its widespread adoption.
The problem with API keys and OAuth consent flows
The two traditional approaches for app-to-app access struggle at scale, though each has its own specific challenges.
API keys
API keys are essentially a password that an application uses to authenticate with an API, or Application Programming Interface. This is a layer that enables different apps to communicate even if they’re written in different languages.
When App A needs to access App B’s API, App B generates a key (usually a quite long random string) that App A includes with every API request. That API validates the key and grants access.
The problem is how these keys are managed in actual practice. Most API keys are:
Long-lived (meaning they don’t expire unless manually revoked)
Over-scoped (they have broad access rather than permissions for only what’s essential)
Decentralized (spread out across config files, environment variables, local machines, etc.)
This is why when an API key leaks (and they often do), enterprises face huge security liabilities. With no centralized inventory of which systems hold keys to what resources, and no automatic expiration or rotation, revocation usually requires coordination across teams to limit damage. Meanwhile, keys are often stored across multiple services, making selective revocation impossible without potentially breaking production.
While you can implement key rotation, scoping, and centralized management of API keys, most organizations struggle to do this consistently across their many, many applications. And most simply choose not to, because it isn’t built-in, and they have other priorities.
OAuth consent flows
OAuth consent flows, which are a core part of the Open Authorization (OAuth) specification, address some of the API key issues by introducing time-limited access tokens and user-controlled permissions. Instead of App A holding a permanent key to App B, the flow works like this:
App A redirects the user to App B’s authorization server
User logs in and sees a consent screen: “App A wants to access your calendar data”
The user approves, and App B issues an access token with specific scopes and an expiration for App A
App A uses this token to make API calls
This is obviously much more secure than API keys: It handles the long-lived access problem, tackles the trouble with over-scoping (assuming the app doesn’t request outlandish scopes), and adds some user-facing elements for some (but limited) visibility into what’s going on.
The real challenge arises at enterprise scale, when you’re dealing with hundreds of apps, thousands of users, and the need to enforce non-negotiable security policy across all of it. Below are just a few of the struggles organizations face when using OAuth consent flows for app-to-app API access at scale:
User experience friction: Because each integration takes a separate OAuth flow, a new employee connecting Slack, Trello, Google Calendar, Salesforce, HubSpot, and GitHub might click through a dozen consent screens before they can even start working. Multiply this across every employee and every app integration.
IT visibility is limited: These OAuth connections happen directly between the user and the apps, meaning IT is out of the loop by default. When an employee authorizes “Generic Marketing Analytics Tool #43” to access sensitive customer data in Salesforce, IT/InfoSec has no centralized view of that happening. The authorization lives in the Salesforce settings for that user.
Fragmented access management: While not buried as deep (or in such varied places) as API keys, revocation still requires security teams to log into each resource app individually, find the authorized connections, and disable them. There’s no built-in visibility that shows “which apps can access what data across our organization.”
Policy gaps: IT/InfoSec can’t pre-approve safe integrations or block risky ones. Every authorization decision happens at the user level, in the moment, without organizational policy enforcement until after the fact.
For enterprise use cases, the recurring issue between both of these approaches is that there’s no unified governance layer to revoke access, observe connections, and enforce policy.
What enterprises need is:
Centralized visibility into all app-to-app connections
Policy-based access control managed by security teams, not individual users
Short-lived credentials that expire automatically
Audit trails that show which app access what data, and when
The ability to revoke access instantly from a single point of control
These are the problems that ID-JAG/XAA was designed to solve.
How ID-JAG/XAA works
In a nutshell, the Identity Assertion JWT Authorization Grant (a.k.a, Cross-App Access) extends enterprise SSO patterns to app APIs. ID-JAG/XAA lets IdPs govern which applications can access other applications’ APIs, with enforcement that supersedes the user level.
It may sound quite similar to the OAuth consent flow (but with observability and policy baked in), and there’s a good reason for that: It’s based on the same underlying standards. However, the key difference from traditional OAuth consent flows is that instead of apps establishing direct trust with each other, the enterprise IdP mediates every connection. IT/InfoSec can pre-approve (or pre-deny) which integrations are allowed, and the IdP issues short-lived, scoped tokens only when policy permits.
OIDC and keys
ID-JAG/XAA invokes the IdP’s existing private key that it uses to sign JWTs, or JSON Web Tokens. The IdP publishes its public key so other entities, like resource apps, can verify its signature on a JWT is legitimate. This is the same signing mechanism used in standard OpenID Connect (OIDC) ID tokens. The resource app already trusts the IdP for SSO (fetching its public keys to validate ID tokens), and ID-JAG/XAA simply leverages that relationship.
The ID-JAG/XAA flow
The protocol involves three parties: the requesting app (the one that needs API access), the resource app (the one that owns the API), and the enterprise IdP (which governs/mediates the connection).
Here’s how the token exchange works:
The user authenticates with the IdP via SSO, receiving an ID token (as in a standard OpenID Connect, or OIDC, flow)
The requesting app requests exchange of the ID token for an ID-JAG at the IdP’s token endpoint as per RFC 8693 token exchange.
The IdP validates the request against company policy: Is the requesting app allowed to access this resource app? Are these scopes permitted for this user?
If approved, the IdP issues an ID-JAG (a signed JWT, or JSON Web Token) back to the requesting application
The requesting app presents the ID-JAG to the source app’s authorization server using the JWT Bearer grant type (RFC 7523).
The resource app validates the ID-JAG signature using the IdP’s public keys (the same JWKS, or JSON Web Key Set, used for OIDC), then issues a short-lived access token
The requesting app makes API calls with the access token until it expires (typically within 10-15 minutes)
ID-JAG vs. XAA
In the US, many people call all glass cleaner “Windex” regardless of the actual brand, or all tissues “Kleenex” despite a pack being of different make. Something similar is happening with Cross-App Access (XAA) and the Identity Assertion JWT Authorization Grant (ID-JAG).
ID-JAG is the OAuth extension being standardized through the IETF. It’s a technical specification that defines exactly how identity providers issue assertion tokens that apps can exchange for access tokens. Any IdP can implement ID-JAG because it’s part of an open standard.
XAA is Okta’s product name for their implementation of ID-JAG. Okta has driven both the IETF standardization effort and early industry adoption. Their branding and developer advocacy have made “XAA” the term many people encounter first, and the one they likely stick with.
The result is what you might expect: XAA is becoming shorthand for the extension. It is, after all, less of a mouthful, and even writing out its full name is clearer at face value than an acronym with another acronym inside it (i.e., the “J” in ID-JAG is for “JWT”).
It’s worth recognizing the effort Okta put into pushing this spec forward, but it’s also helpful to remember that XAA is not the only option for implementing the extension. It is still very much an open standard that any organization can implement.
Why AI is driving ID-JAG/XAA adoption
While ID-JAG has solid solutions to long-standing enterprise problems in app-to-app connections, AI agents have made finding a solution urgent rather than a luxury.
An agent that needs to check your calendar, create a Zoom meeting, update a project tracker like Trello, and send a Slack notification faces constraints that traditional applications simply don’t. The agent can’t pause its workflow to complete OAuth consent screens, and it can’t safely hold semi-permanent API keys to every system it might need to access.
Traditional approaches to agentic app-to-app access
We’ve seen several approaches to resolving this issue for agents:
API keys, as previously mentioned, can’t be trusted with agents. Agents are still too unpredictable for them to hold these typically overscoped credentials.
OAuth consent flows are a step up, but aren’t viable for workflows where agents might need to talk with dozens of applications: “I need you to approve Slack…now Zoom… now Asana…” defeats the value of many agentic scenarios.
Service accounts with broad access have seen use by some organizations, giving dedicated access rights to the agent. Except this invites a new problem: The agent operates with its own fixed identity that isn’t tied to the user making requests. This is obviously less than ideal for visibility.
How ID-JAG/XAA helps AI agents connect with apps
With ID-JAG/XAA, an AI agent requests tokens through the enterprise IdP, on-demand and not as a persistent or long-lived set of credentials. When the agent needs to access Salesforce, for example, it exchanges its ID token (from when the user authenticated with SSO) for a scoped, short-lived token that permits only the specific capabilities needed for the task at hand.
The token expires automatically, the request is logged (traceable back to the user and agent), and IT/InfoSec maintains policy control over which agents can access which resources. This dovetails neatly with how enterprises actually think about agentic security: agents should act on behalf of users, with permissions derived from those users’ access rights, not operate as independent, un-monitorable entities with overly broad scopes.
IT/InfoSec can define policies like which types of agents can access which types of apps and what their permissions are within those environments: reading calendars (but not writing to them), adding meetings (but only for Zoom, not Google), and so on. These policies are enforced at the IdP level rather than requiring each application to implement its own agent auth logic for every possible interaction.
Securing and simplifying app-to-app access
The Identity Assertion JWT Authorization Grant extends enterprise SSO to API access, replacing un-scaleable static credentials and fragmented OAuth flows with IdP-mediated, short-lived tokens. While the specification addresses a problem that’s existed for quite some time across SaaS integrations, AI agents have accelerated the adoption and ignited the drive to finalize its publication.
Agents can’t (or, at least, shouldn’t) operate with API keys stored in their systems, and OAuth flows defeat much of their utility. ID-JAG/XAA offers an elegant solution that puts control back in the hands of enterprise security teams.
If you’re building AI agents (or apps that need to talk with them) and are looking to secure complex, multi-step workflows, join the Descope dev community, AuthTown. Start off on the right foot with agentic identity by signing up for a Free Forever Descope Account, and leverage our Agentic Identity Hub for granular, enterprise-ready AI authentication and access control.
