Archestra Logo
Archestra.AI
2026-06-23

Archestra now supports Okta's Cross-App Access

Archestra is joining Okta's Cross-App Access (XAA) ecosystem, bringing identity-based, per-user access to AI agents and MCP without shared API keys or repeated consent flows.

Archestra now supports Okta's Cross-App Access

Written by

Joey Orlando

About six months ago, we at Archestra realized that MCP adoption inside large organizations slams into an impassable wall — authorization at scale. The teams running an MCP rollout can't realistically ask several thousand — sometimes tens of thousands — of end users to spend half an hour setting up API keys, or to click through an OAuth 2.1 flow across a few dozen MCP servers.
That's exactly why we dove headfirst into MCP Enterprise Auth while it was still raw, and back in March we became the first of 110 (!) MCP clients to ship support for it (PR #3516). I even wrote about it in a three-part series — here, here, and here. But the whole time, one problem was sitting there: we couldn't be the only client supporting ID-JAG and Enterprise Auth. The pattern only works when three sides show up — the identity provider, Archestra, and the third-party service.
For a long time, we carried Enterprise Auth in proud solitude — and finally, the ice broke! Last week, the official MCP blog put a spotlight on MCP Enterprise Auth, and the post spent the whole day at the top of Hacker News (though it stung a little that they didn't name us).
And today, we couldn't be more excited to share it: Okta is announcing Cross-App Access (XAA), and Archestra is in the launch lineup alongside Asana, Atlassian, Canva, Cloudflare, Cursor, Datadog, Docker, Figma, Linear, WorkOS, Zoom, and others 🎉!
MCP Enterprise Auth is the MCP-side spec, ID-JAG is the OAuth-side grant under it, and XAA is Okta's productization that makes the whole thing shippable in production.

What XAA actually changes

XAA replaces static credentials and repeated consent flows with identity-based access that runs through your existing IdP.
Instead of storing API keys, the agent requests access through Okta. Okta issues a token for a specific user, a specific application, and a specific set of permissions.
The connection runs through the identity infrastructure your company already trusts for SSO.
The part that matters for us: XAA isn't a proprietary Okta feature. It's an extension of OAuth, and it's been formally incorporated as an official MCP authorization extension — open and vendor-neutral. The official MCP SDKs are adopting it as the Enterprise-Managed Authorization extension, with TypeScript and Java support available now and Python on the way.
Okta sorted its 20 launch partners into three groups: the apps that request access (e.g., AI agents running in Archestra, or coding tools like Cursor), the apps that hold the data (Asana, Atlassian, Datadog, Figma, Linear, and the rest), and the identity providers that govern access (e.g., Okta itself).
Archestra sits in the middle and coordinates the flow between them. Whether you're running agents inside Archestra or connecting through an Archestra MCP Gateway, we handle the authentication flow and token exchange that make XAA work.
Loading diagram...
In short: if you're using both Archestra and Okta, you can hand your users a single MCP Gateway and they're authenticated to every MCP server behind it — "automatically".

Does XAA kill MCP gateways?

Yes! But only some of them. In Archestra's early days, we burned an incredible amount of effort "compensating" for the absence of XAA on behalf of our customers, and we're genuinely glad we can now focus on what our users actually value us for — security, logging, data-exfiltration protection, and the agent runtime.
If your "MCP gateway" only exists to sit between an agent and a tool, hold a static key, and forward requests, XAA makes that model much less useful. When authentication moves into the identity layer, the gateway should no longer be the place where access is faked with shared credentials.

MCP is moving in the right direction

This is good news for MCP, and we're happy to see the protocol move in this direction.
We believed this was the right path early on: MCP access should be managed through the identity systems companies already trust, not through shared keys and one-off auth flows. Now Enterprise-Managed Authorization is a stable MCP extension, not just an Okta feature sitting beside the protocol. That's a big step for enterprise MCP adoption.

Resources

P.S. We're watching you very closely, Entra ID. Very closely. 👀