Beginning in October, Okta release version notations are changing from year.month to year.week. For example, 2026.10.0 will become 2026.41.0, where 41 indicates that week of the year that the deployment occurs. More information is available in this knowledge base article.

    On this page

    Enable Cross App Access (XAA): Build a resource app

    Make your API accept authenticated cross-app calls from other apps using a signed-in user's Okta identity.

    Introduction

    Cross App Access (XAA) lets an app call your API on behalf of a user who is already signed in through Okta, without static API keys or a second sign-in prompt.

    As a resource app (such as an API service, web app, or Model Context Protocol (MCP) server), your API handles requests from requesting apps (for example, automation workflows, AI agents, or chat integrations). A requesting app exchanges a signed-in user's Okta identity for a temporary token called an ID-JAG. Your authorization server validates the ID-JAG and issues an access token for your API.

    Note: XAA builds on SSO. Your app must already have an enterprise SSO configured (OIDC or SAML) for authentication. It may or may not already use Okta as its identity provider. If you're starting from scratch, set up SSO first.

    This journey covers the resource app role only. If you're building the app that initiates the call, see Enable Cross App Access (XAA) for a requesting app.

    What you accomplish

    By the end of this journey:

    • Your authorization server accepts incoming XAA requests from requesting apps and returns scoped access tokens.
    • Your authorization server validates incoming ID-JAG tokens and correctly rejects tokens with the wrong type, mismatched audience, or insufficient scope.
    • You have a tested, end-to-end XAA flow that passes the xaa.dev conformance tests.
    • Your integration is ready to submit to the OIN catalog through the OIN Wizard, with the xaa.dev conformance log as test evidence.

    Learn

    New to Okta? Understand these concepts:

    • Okta org: Serves as your central Okta development hub, encapsulating all configurations, users, groups, policies, and other objects that your app uses.
    • Identity and Access Management (IAM) overview: Learn the key issues and concepts for adding identity and access management to your internal and external services.

    Understand these before you build:

    • Cross App Access overview: Understand how XAA works and how it layers over OIDC or SAML.
    • ID-JAG token: The token Okta issues to the requesting app. Your authorization server validates its type, audience, and claims before it issues an access token for your API.

    Note: XAA supports both OIDC and SAML implementations. Okta recommends OIDC for new integrations. Existing SAML implementations don't require protocol migration.

    Plan

    Verify the following readiness requirements before implementation:

    More planning considerations:

    • Decide which scopes your API exposes and which requesting apps you allow initially.
    • Decide what to log per call: requesting app (act.sub), user (sub), scopes, time stamp.
    • Decide your resource authorization server's issuer URL. It becomes the aud claim in every ID-JAG that your server receives, and it can't be changed without resetting the XAA connection.

    Build

    Choose your path

    1. If you're new to Okta, build your SSO integration first (OIDC or SAML), then follow the steps after this. You add Cross App Access in the same OIN Wizard submission.
    2. If your SSO app is already on the OIN, see the following steps, then extend your existing integration from your OIN integrations.

    If you have your SSO app listed on OIN, follow these steps:

    1. Expose XAA discovery metadata: Publish .well-known/oauth-authorization-server metadata with the two XAA properties and .well-known/oauth-protected-resource (required for MCP servers, recommended for other resource servers), so requesting apps can discover your token requirements.
    2. Validate the ID-JAG at your authorization server: Configure your authorization server to accept the ID-JAG (jwt-bearer grant type), validate it, and issue a scoped access token.
    3. Validate access tokens at your API: Your API validates the access token your authorization server issues, as it does for any other token. If you already do this, no change is needed.
    4. Enable XAA on your resource app and add a connection: In the Admin Console, enable XAA on your resource app, then add a resource connection so that xaa.dev can reach it. For SAML apps, set the Name ID format to EmailAddress.

    Note: Your API's audience URL must match the requesting app's configuration exactly, including trailing slashes. A mismatch is a primary cause of token validation failures. Don't issue refresh tokens for XAA exchanges. Requesting apps are required to submit a fresh ID-JAG upon access token expiration.

    Validate

    Test your flow end to end on xaa.dev (opens new window), which acts as the requesting app. Run the tests until conformance passed appears, then export the JSON conformance log. For OIN submission, follow the xaa.dev testing steps in the OIN submission guide. If a test fails, see Handle errors and troubleshoot in the ID-JAG validation guide.

    Note: For further guidance and examples, see the following blogs:

    Go further

    Congratulations, your API is now XAA-enabled. Here's how to expand your integration and reach enterprise customers:

    Edit This Page On GitHub