Okta this week is introducing Cross App Access (XAA) at Oktane, a new standard designed to let a user’s existing SSO session authorize downstream applications without requiring a separate consent flow for each one. In the MCP ecosystem, the broader model is known as Enterprise-Managed Authorization (EMA).
We’re launching support for both today as an Okta launch partner, while also giving enterprises a way to bridge XAA with the standards already in their environments. Here’s what it does, why we built it, and how Aembit is making XAA adoption easier for enterprises.
What Problem Does Cross App Access (XAA) Solve for AI Agents?
Okta introduced Cross App Access (XAA) as an enterprise identity standard that lets a user’s existing SSO session authorize an AI agent’s access to a downstream application without a separate manual consent step for that application.
As more and more workforce agents are tasked with accessing a growing number of SaaS-hosted MCP servers, the brief friction of the consent-screen quickly becomes a massive bottleneck. Every upstream server – Jira, Confluence, Asana, whatever your agents need to touch – has required its own manual OAuth Authorization Code flow. A user clicks through a consent screen, an access and refresh token pair gets minted, and that token becomes the credential for that one server.
That process works, but it’s a lot of clicking for an enterprise running agents against dozens of tools. XAA fixes that by letting the user’s already-established corporate SSO session stand in for that manual authorization.
The problem? Almost nothing supports XAA yet. Because this is a new standard, support is rolling out gradually and most upstream MCP servers won’t have XAA-compatible authorization servers for a while. If you wait for every piece of your stack to support XAA natively before using it anywhere, you’ll be waiting a long time.
The solution? Aembit both works with XAA through our Enterprise-Managed Authorization Credential Provider and brokers between XAA and other standards when XAA isn’t supported by the resources your agents are trying to access.
How Does Aembit’s Enterprise-Managed Authorization Credential Provider Work?
Aembit already sits as the enforcement point and gateway between your agents and upstream MCP servers. XAA support is just a new credential provider type on top of that existing architecture.
At a high level, three things happen:
- Token capture at login. When a user completes SSO through their corporate IdP (with the
offline_accessscope enabled), Aembit captures both the ID token and refresh token, encrypts them, and persists them. - Centralized background refresh. A background job checks for tokens nearing expiration and refreshes them proactively, so the token exchange on the actual request path never has to wait on a slow round trip to the IdP.
- Dual exchange at request time. When an agent calls an upstream MCP server, Aembit’s Edge Controller exchanges the user’s ID token for a short-lived assertion scoped to the target server, then presents that assertion to the upstream authorization server for an access token. The result is cached in memory for the life of its validity.
Aembit can issue that intermediate assertion two ways. If the corporate IdP itself supports the exchange, Aembit requests it directly from the IdP. If the IdP doesn’t support it yet, but the upstream MCP server trusts Aembit directly, Aembit generates and signs the assertion itself using the tenant’s own keys. Either path produces the same result for the agent and the upstream server, so you don’t need your IdP and every SaaS MCP server to simultaneously reach XAA maturity before you get the benefit.
Does XAA Support Replace Aembit’s Existing OAuth Authorization Flow?
The short answer is no.
The long answer? XAA support is a second authorization path that runs alongside Aembit’s existing standard OAuth flow, not a replacement for it. If a target MCP server doesn’t support XAA at all, or a user’s IdP session doesn’t have the required scope, Aembit falls back to the standard manual pre-authorization flow automatically. Nothing breaks, and existing Aembit deployments don’t change.
Okta, Entra ID, or whichever OIDC provider an organization runs, remains the source of truth for who the user is. Aembit’s role is to use that source of truth to create the blended human-agent identity that informs what MCP servers, tools, and resources the agent can access and cut off that access when it’s no longer needed.
Why Does the Broker Model Matter Right Now?
XAA could become the standard answer for enterprise-to-SaaS authorization over time, but that doesn’t mean it’s usable today across a real enterprise stack. Enterprises don’t run a single IdP talking to a single SaaS vendor; they run a mix of identity providers, dozens of SaaS tools, and a growing set of AI agents that need to reach all of them. Very few of those pairings will have native XAA support on both ends anytime soon.
Aembit’s Enterprise-Managed Authorization Credential Provider is built to sit in that gap: broker the exchange regardless of which side of the pairing is ready, fall back where neither side is, and give administrators one configuration surface instead of a growing list of one-off integrations. With Aembit, the zero-touch experience XAA promises is usable now, so enterprises don’t need to wait on the wider ecosystem to catch up.
How Do I Get Started With Aembit’s XAA Support?
The Enterprise-Managed Authorization Credential Provider is generally available today. Enterprises running agents against SaaS-hosted MCP servers can talk to an Aembit engineer or head to the docs to configure it against their own identity provider and stack.
