Build Secure Agent-to-App Connections with Cross App Access (XAA)

Developer Blog Comments
1

Secure access with enterprise IT oversight between independent applications that communicate with each other is a recognized gap in OAuth 2.0. Enterprises can’t effectively regulate cross-app communication, as OAuth 2.0 consent screens rely on users granting access to their individual accounts. Now, with the advent of AI agents that communicate across systems, the need to solve the gap is even greater – especially given the growing importance of enterprise AI security in protecting sensitive data flows.

This is a companion discussion topic for the original entry at https://developer.okta.com/blog/2025/09/03/cross-app-access
2

Hi,

I’ve been experimenting with Cross App Access based on this post and the Agent0/Todo0 sample, and I have a question about the required architecture.

In your example, Okta acts as the IdP and there’s a separate authorization server for the resource app (e.g., the Todo0 authorization server). In my setup I have:

  • One Okta org (my “integrator” instance)

  • Two apps in that same org:

    • A web UI app that does OIDC login with Okta (Auth Code + PKCE)

    • A backend “resource server” app that I want to call via Cross App Access

My questions are:

  1. Can Cross App Access / ID-JAG be used when both the requesting app and the resource app live in the same Okta org, and the resource’s authorization server is also that same org (e.g., via a custom authorization server like /oauth2/default)?

  2. Or is it a requirement/recommendation that the resource app have its own authorization server, separate from the enterprise IdP – like in your sample (a custom auth server) or possibly a second Okta org acting as the resource authorization server?

  3. If using only a single Okta org is supported, is there a minimal example or configuration you can point to that shows ID-JAG working without a separate non-Okta auth server?

I’m trying to understand the intended deployment model so I can get this working correctly with my own Okta “integrator” instance.

Thanks!

4

Hi @dharm.ace, thanks for reaching out, and good to know you’re trying out the sample repo.

Regarding your questions:

1. Using Cross App Access / ID-JAG within a single Okta org

Currently, Cross App Access is designed for scenarios where the requesting app and the resource app are third-party to each other, meaning each app has its own authorization server in a separate trust domain. We currently support the model in the Okta Integration Network where you add third-party apps using Okta SSO for your workforce.

So while both apps can live as OIDC clients inside your same Okta org for login, their authorization servers should not be the same. We are actively working on supporting “first-party” / internal-only setups like yours, but that isn’t the intended model yet.

2. Whether the resource must have its own authorization server

Yes – that is the current recommendation.
The requesting app and resource app should each have their own authorization server (their own issuer), separate from the enterprise IdP. This separation is what allows ID-JAG to model cross-app trust correctly.

3. Minimal example using a single Okta org

Right now, there is no minimal example where both apps use the same Okta custom authorization server as their AS. Your scenario falls under “first-party/internal apps,” which is on the roadmap but not available yet.

5

Thank you so much for this clarification. There was some confusion in testing the demo and ID-JAG exchange wouldnt work until we explored the Cross App Access (XAA) for Resource Applications Beta . IDP for Requesting app and Auth Server for Resource app need to be separate trust domain which is where GitHub - oktadev/okta-cross-app-access-mcp: The repository demonstrates a sophisticated enterprise integration pattern where an AI-enabled agent application (Agent0) can securely access resources from a separate todo management application (Todo0) without requiring users to authenticate separately to each system. was not working for us while using same Okta tenant.

Follow up question for the resource Authorization Server. Do the Requesting App IDP and Resource Authorization Server need to be federated as mentioned in this Okta(Requesting App IDP)+Auth0(Resource Auth Server) link Cross App Access (XAA) for Resource Applications Beta?

Regarding the roadmap, is there a page that could be referred to identify the following:

  1. Support for first-party/internal apps
  2. Remove dependency on using TODO0 and Agent0 as OIN apps and allowing the ability to Manage connections using Custom OIDC Apps?
6

I need help understanding whether, in an OAuth/OIDC federation scenario where Okta is the Identity Provider and issues an ID-JAG token (ID-JAG) that the requesting app uses to obtain an access token from a downstream resource server, it is possible to customize the sub claim or include additional claims such as email or other profile attributes in the ID-JAG token. Specifically, I’d like to know if Okta supports overriding the sub value (e.g., mapping it to email, username, or a custom attribute) and whether additional claims can be injected into the ID-JAG token for this delegated authorization flow, and if so, where this should be configured—within the OIDC application settings.

7

@nithishsubramani Answer to your questions:

  • The sub claim can’t be customized. ID-JAG tokens always use the Okta user’s immutable Okta ID, and there’s no option to remap it to email, username, or any other attribute.

  • Additional claims (like email or profile fields) can’t be added to the ID-JAG token right now. Custom admin-defined claims aren’t supported for this flow.

One thing to keep in mind is that the downstream OIDC step also relies on this same sub value, so both the requesting app and the resource server are expected to use that Okta ID as the stable identifier.