Skip to main content
Cross App Access (XAA) for the Resource App is in Early Access. Enterprise, B2B Pro, and B2B Essential customers can use it as a feature of Enterprise Connections. You can also try it during the trial period on Free tenants. By using this feature, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement.
By configuring your Auth0 tenant as the Resource App Authorization Server, your SaaS application can start accepting incoming ID-JAG requests without requiring any code changes. This enables you to generate access tokens in response to these requests, allowing AI Agents and other applications to seamlessly consume your MCP or SaaS API.
The XAA end-to-end environment setup includes the following steps:
  1. Configure and register your API in Auth0.
  2. Configure and register your Resource App: This includes configuring your Auth0 tenant and registering your SaaS application as a Resource App with your enterprise IdP.
  3. Configure the Requesting App to test the end-to-end flow: This includes registering a test Requesting App in your Auth0 tenant and linking it to your Resource App in your enterprise IdP. To learn more, read Requesting App setup.
  4. Configure how your Auth0 tenant federates with your customer’s enterprise IdP. For example, if you are testing with Okta, the enterprise IdP will be your Okta test tenant, representing one of your enterprise customers.
This article only covers the Auth0 environment setup. For the enterprise IdP-side configuration in each of these steps, read the applicable guide in IdP Integration — Okta as OIDC IdP, Okta as SAML IdP — depending on the IdP and protocol you want to use to federate with it.

​
Create the API in Auth0

If you have already created a custom API in your Auth0 tenant, you can skip this section.
In the Auth0 Dashboard, register a custom API representing your SaaS API in your Auth0 tenant. If you’re exposing an MCP server, read Authorization for your MCP Server to configure your server to accept only access tokens issued by authorized MCP clients.
After you’ve created the API, you can optionally set its audience as the Default Audience for your Auth0 tenant under Tenant Settings. You can also use API Access Policies for Applications to granularly control which applications are granted access to your API for which scopes.

​
Requesting App setup

In a production environment, you configure each Requesting App once to enable its connection with your Resource App.
To set up your Requesting App, you need to:

​
Create the Requesting App in Auth0

To test the end-to-end environment, create and register an application that behaves as the Requesting App. The following clients are supported:
  • First-party or third-party clients
  • Confidential clients, such as a Regular Web Application
  • Public clients, such as a Native App or Single Page Application
  • CIMD clients or applications registered via Client ID Metadata Document (CIMD)
To create an application representing the Requesting App in your Auth0 tenant:
  • Navigate to Applications > Applications and select Create Application.
  • Enter a name and select Regular Web Application, Native, or Single Page Application depending on the type of application you want to use.
If your application is a third-party application, which is the most common case, you must explicitly configure its API access permissions. To learn more, read Configure API Access Policies.
  • In the application details, note the Client ID of the application. This is required when configuring the enterprise IdP. For CIMD applications, use the External Client ID field.
  • Once you’ve created the application, scroll to Settings and enable the Cross App Access toggle.
Once you’ve created and configured your application, you must configure the enterprise IdP. To learn more, read the applicable guide in IdP Integration for your enterprise IdP and protocol. Once you’ve completed both the Auth0 and enterprise IdP configuration, read End-to-end Testing to test the full flow.