The Model Context Protocol team published Enterprise-Managed Authorization (EMA) as a stable extension on June 18, 2026, removing what has been MCP’s biggest enterprise deployment blocker. Previously, every employee had to manually OAuth into each MCP server individually—a process that created ticket queues for IT teams and left security with no centralized control, no audit trail, and no reliable way to revoke access when someone left the company. EMA flips that model entirely: administrators configure MCP enterprise authentication once in their identity provider, and employees get all approved connectors automatically on first login.
The Per-User OAuth Problem Was Real #
Anyone who has tried to deploy MCP tools across a team larger than a few developers knows the friction. Each new hire needed to manually authorize each MCP server—Figma, Linear, Atlassian, Supabase—separately, through per-server OAuth consent screens. IT had no visibility into who had access to what. Offboarding was a multi-step manual process across a dozen individual services. Security teams could not enforce consistent policies because each user effectively managed their own authorization state.
Cameron Leavenworth at Ramp put it plainly: “Before enterprise-managed auth, onboarding…meant a queue of per-connector OAuth approvals. Now they log in on day one already connected.” That queue is the problem EMA eliminates at the protocol level—rather than patching it with a gateway or custom tooling.
Related:[MCP Has 1,800 Unauthenticated Servers in Production. Here’s Your Exposure.]
How EMA Works: One Login, All Connectors #
EMA introduces the Identity Assertion JWT Authorization Grant (ID-JAG), built on RFC 7523. The flow: a user logs into their MCP client—Claude or VS Code—via corporate SSO. The identity provider evaluates policy (group membership, role assignments, conditional access rules) and issues a short-lived ID-JAG token. The MCP client exchanges this for an access token from the MCP server’s authorization server. The user never sees a per-server consent screen.
MCP clients declare EMA support in the initialize
request using the extension identifier:
{
"capabilities": {
"extensions": {
"io.modelcontextprotocol/enterprise-managed-authorization": {}
}
}
}
Revocation happens at the IdP level. Remove a user from the relevant Okta group and their access to all connected MCP servers disappears immediately—no need to revoke across each server individually. This is what actual enterprise access control looks like. Hacker News has called the pre-EMA situation “identity dark matter”: AI agents accumulating access across systems with no IAM visibility. EMA makes that access visible and manageable. The full technical specification is available in the ext-auth repository.
Who Supports EMA at Launch #
Day-one adoption is broad enough to matter. On the identity provider side: Okta, via their Cross App Access (XAA) protocol. On the client side: Anthropic’s Claude (available in beta on Team and Enterprise plans) and VS Code version 1.123 and later. On the MCP server side: Asana, Atlassian, Canva, Figma, Linear, and Supabase—with Slack coming soon. Early enterprise adopters already running EMA include HubSpot, Ramp, and Webflow.
Tom Moor from Linear captured the user experience shift: “Logging in once and automatically having all your MCP connectors automatically setup is pretty magical.” However, there is an honest limitation to call out: Azure AD users are waiting. Anthropic says more identity providers are coming, but Okta-only at launch means a significant portion of enterprises are not yet served. If your organization runs on Azure AD or Google Workspace SSO, EMA is not ready for you yet.
What MCP Server Builders Should Do Now #
If you are building an MCP server and want enterprise customers, EMA support is the path forward. The implementation steps: declare the extension in your server’s authorization metadata, validate incoming ID-JAG JWTs against the IdP’s JWKS endpoint, and map IdP claims to your permission model. Okta’s TypeScript and Java SDKs already include XAA support, so if you are using either of those, the IdP integration work is largely done for you.
The window to get ahead of this is now. When Figma, Atlassian, and Linear all implement the same enterprise authentication standard simultaneously with Anthropic and Microsoft, it becomes the de-facto approach. Enterprise IT teams will start asking which MCP servers support EMA before approving deployment. Better to have that answer ready.
Key Takeaways #
- EMA went stable on June 18, 2026—admins configure MCP server access once in their IdP, employees get it automatically on login with no consent screens.
- Okta is the only supported identity provider at launch. Azure AD and Google Workspace SSO are on the roadmap but not yet available.
- Day-one client support covers Claude (Team/Enterprise beta) and VS Code 1.123+. Server support includes Asana, Atlassian, Canva, Figma, Linear, and Supabase.
- MCP server builders should implement EMA support now—enterprise IT teams will require it. The specification is at github.com/modelcontextprotocol/ext-auth. - Revocation is instant and centralized: remove a user from the IdP group and access disappears across all connected MCP servers immediately.