MCP Enterprise-Managed Authorization ends per-user OAuth chaos

Manoranjan Rajguru's article opens with a concrete illustration of what he calls the "auth tax": a 500-person organization deploying AI workflows via MCP-connected tools like Figma, Linear, Confluence, and Supabase would generate 4,000 individual OAuth consent flows — before accounting for new hires, role changes, offboarding, or token expiry. Standard MCP authorization is built around user-scoped, interactive OAuth flows: each client performs Dynamic Client Registration against an MCP server's Authorization Server, the user is redirected to a consent screen, grants permission, and receives an access token scoped to that user-and-server pair. The article identifies four structural failure modes at enterprise scale: onboarding effort scales linearly with the number of MCP servers; security teams have no central record of who has access to which server; personal and corporate accounts can be mixed without enforcement, creating SOC 2 and ISO 27001 compliance risks; and offboarding requires manually revoking access on every MCP server individually, with tokens potentially remaining valid until their TTL expires.

The core premise is that enterprises already maintain a system of record for identity — Okta, Azure Entra ID, Auth0, Google Workspace — and MCP servers should be governed by that same system.

The Enterprise-Managed Authorization extension (`io.modelcontextprotocol/enterprise-managed-authorization`), published as a stable spec on June 18, 2026 and backed by Anthropic, Microsoft, and Okta, addresses these failure modes by inserting the organization's existing Identity Provider as the authoritative decision-maker for all MCP server access. The core premise is that enterprises already maintain a system of record for identity — Okta, Azure Entra ID, Auth0, Google Workspace — and MCP servers should be governed by that same system. The article describes the end-user experience as "zero-touch connector setup," and notes that VS Code 1.123 already ships EMA support. The article also references a token exchange mechanism called the ID-JAG Token Exchange and covers implementation guidance for both MCP client and MCP server developers, though the source text is truncated before those sections are fully detailed.

Key facts

1. 01The stable EMA extension (`io.modelcontextprotocol/enterprise-managed-authorization`) was published on June 18, 2026.
2. 02EMA is backed by Anthropic, Microsoft, and Okta.
3. 03Standard MCP auth requires per-user, interactive OAuth consent flows — one per user per MCP server.
4. 04A 500-person org using 8 MCP servers would face 4,000 individual OAuth consent flows under the standard model.
5. 05EMA designates the organization's IdP (e.g., Okta, Azure Entra ID, Auth0, Google Workspace) as the authoritative decision-maker for all MCP server access.
6. 06VS Code 1.123 already ships EMA support.
7. 07The article identifies offboarding, audit trail gaps, and personal/corporate account blurring as key failure modes of standard MCP auth.

Topics