Cross-App Access (XAA) is one of 28 APIs that Okta publishes on the network. It is an OAuth profile for agent-to-app and app-to-app authorization, built on the IETF draft OAuth Identity Assertion Authorization Grant — ID-JAG, draft-ietf-oauth-identity-assertion-authz-grant.
The mechanism: an identity provider mints an identity assertion, and a downstream resource application exchanges that assertion for a scoped access token. No long-lived credential is ever provisioned between the agent and the SaaS app.
The problem it deletes
Right now, connecting an agent to a SaaS application means creating an API token in that application, storing it somewhere, and granting it whatever scope the token model allows — usually more than the task needs, always for longer than the task lasts.
Multiply by every app in an enterprise and you have a credential sprawl problem that no one owns. The tokens are unmanaged, they outlive the projects that created them, they carry the permissions of whoever generated them, and they are invisible to the identity team that is nominally accountable for access.
XAA moves that decision back to the IdP, where it was supposed to live. The agent presents an assertion about who it acts for; the resource app decides what that identity may do; the resulting token is scoped and short-lived.
What Okta actually published
The artifact set is more interesting than most:
- Documentation and a public sandbox at xaa.dev — a live playground for testing both requesting and resource application implementations
- The specification itself, linked to the IETF datatracker draft
- Two engineering blog posts — the January 2026 xaa.dev introduction and the February 2026 walkthrough on making secure app-to-app connections
- An apis.json index and Arazzo workflows on the Okta provider entry
Publishing the IETF draft as a first-class property is the part worth noting. Most vendors announcing a protocol link to their own explainer. Okta links to the standards document, which invites the reader to check whether the implementation matches the spec.
The sandbox is the real artifact
xaa.dev is a public, running implementation you can test against without an Okta contract. That is rare, and it is the difference between a protocol proposal and a protocol you can adopt.
It is also a signal about intent. A vendor building a proprietary moat does not stand up a free sandbox that helps you implement the client half against anyone’s server. A vendor trying to make a draft into a standard does exactly that.
The honest caveat
This is a draft. draft-ietf-oauth-identity-assertion-authz-grant is working-group material, not a published RFC, and the shape can still change. Building on it today means accepting that you may be revising against a later revision.
The alternative is the status quo: long-lived unmanaged tokens sitting in agent environments across every SaaS app in the estate. That is not a safer bet, it is just an older one.
Takeaway
An emerging OAuth profile that removes standing credentials from the agent-to-app path, published with the IETF draft, an engineering walkthrough, and a public sandbox anyone can test against. It is draft-stage and Okta is not hiding that.
Try it at xaa.dev, and see the provider entry at apis.io/providers/okta/.