Skip to main content
Cross App Access (XAA) is currently in Beta. By using this feature, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement. To learn more about Auth0’s product release cycle, read Product Release Stages. To participate in this program, contact Auth0 Support or your Technical Account Manager.
This guide assumes you use Okta as your enterprise identity provider (IdP) and have administrative access to an Okta tenant you can use for testing. If you don’t have one, read Create and configure your Okta tenant.
Connecting third-party apps and AI agents in an enterprise creates two key problems: poor IT visibility into data sharing and repetitive consent flows for users. Cross App Access (XAA) addresses these challenges by allowing IT admins to centrally define access controls for how SaaS applications, like AI agents, connect on a user’s behalf. Admins manage these connections in a central dashboard, like the Okta Admin Console, which eliminates disruptive OAuth consent prompts for end-users. The result is improved organizational security, governance, and user experience. XAA implements the Identity Assertion Authorization Grant, an in-progress OAuth extension that allows an AI agent or application (Requesting App) to obtain a secure token through the enterprise IdP. This token enables the Requesting App to call the APIs of another application (Resource App) on the end-user’s behalf. To learn more, read How it works.

​
Key benefits

XAA delivers key benefits for every role in your enterprise ecosystem:
  • For Enterprise IT administrators: Centralized control, visibility, and policy enforcement over application access to enterprise and user data.
  • For SaaS providers and developers: Standardized and secure integration for enterprise AI to foster ecosystem growth.
  • For end-users: Streamlined and frictionless connections between applications, eliminating complex OAuth consent flows.

​
Use cases

Common use cases for XAA include:
  • Connect AI agents to enterprise applications: An employee uses an AI agent to read from their calendar app and post an update about their availability in the enterprise messaging app. Instead of requiring the employee to go through redirection flows and consent prompts, the AI agent uses XAA to obtain an access token from the enterprise IdP to securely call the APIs of both the calendar and messaging app, if approved by the enterprise access policy.
  • Connect SaaS applications: In our previous example, the enterprise calendar and messaging app both support XAA. Employees can seamlessly connect the messaging app to access the calendar app’s API without user redirection or consent while following enterprise access policies.

​
How it works

The XAA flow involves the following actors:
  • Requesting App: The application or AI agent that needs to access a resource.
  • Resource App: The application that owns the protected resource and exposes it via an API
  • Enterprise IdP: The IdP, such as Okta, that authenticates employees.
After the end-user authenticates with the enterprise IdP, the Requesting App contacts the enterprise IdP to request access to the Resource App on the user’s behalf. After applying its access policy to check if this cross-app connection is permitted, the enterprise IdP generates an assertion called an ID-JAG, which the Requesting App then presents to the Resource App to get an access token for API consumption.  In the following diagram, Acme is the enterprise customer whose employees authenticate with their enterprise IdP, such as Okta, to access the Requesting App (Agent0) and the Resource App (Todo0):
  • The Resource App (Todo0) Authorization Server is federated with the enterprise IdP through OIDC so that it can generate access tokens for end-users authenticated by that IdP.
  • The Requesting App (Agent0) is registered with the Resource App Authorization Server as an OAuth 2.0 client with a valid client_id and credentials to request access tokens from the Resource App Authorization Server.
  • The Acme IT admin has defined XAA access controls between Agent0 and Todo0.

​
End-to-end XAA flow

With our Acme example in mind, the end-to-end XAA flow has the following steps:
  1. The Acme employee logs into the Requesting App (Agent0) using SSO with the enterprise IdP. The Requesting App obtains an ID token to verify the Acme employee’s identity.
  2. The Requesting App makes a token exchange request to the IdP to exchange the ID token for a cross-domain Identity Assertion JWT Authorization Grant, also known as ID-JAG. The IdP validates the request and checks the XAA policy defined by the Acme IT Admin.
  3. If the XAA policy allows for it, the IdP returns the ID-JAG to the Requesting App.
  4. The Requesting App makes a token request using the ID-JAG to the Resource App (Todo0) Authorization Server.
  5. The Resource App Authorization Server validates the ID-JAG using the public key it also uses for its OpenID Connect flow with the IdP. If valid, the authorization server returns an access token.
  6. The Requesting App makes a request with the access token to the Resource App’s API.
Leveraging the XAA flow, Acme’s IT admin policies govern access from Agent0 to Todo0, requiring no end-user redirection or interaction.

​
Beta limitations

XAA Beta has the following limitations:
  • The Requesting App must be a confidential client and a first-party app in your Auth0 tenant. Public clients, such as SPAs and Native Apps, are not supported.
  • Delegated administration is not supported. The enterprise customer cannot directly configure SSO connections on your Auth0 tenant. Self-Service SSO support is planned for a later release.
  • There can only be one XAA-enabled connection per upstream IdP issuer. The same Okta tenant can’t be used for more than one XAA-enabled enterprise connection.
  • Organization support is limited:
    • A connection has a 1:1 assignment with an Organization. Multiple Organizations cannot map to the same connection for XAA access.
    • When the Requesting App is configured to require the use of Organizations, users must already be members of the target organization.
  • If the resource parameter is not specified in the ID-JAG request, the target API is determined by the tenant.default_audience.
  • No dynamic user creation: The user must have previously logged into your Resource App using the configured Okta connection. Otherwise, the request to exchange the ID-JAG assertion for an access token will fail with a User not found error.

​
Rate limits

In XAA Beta, ID-JAG exchanges on the /token endpoint of your Auth0 tenant will be rate-limited to 5 RPS.