MCP Enterprise-Managed Authorization is stable: how IdP-provisioned connector access replaces per-server OAuth hell

Introduction

MCP adoption in enterprises stalled for a predictable reason: OAuth fatigue. Every connector meant every employee clicking through a consent screen for Jira, then Linear, then Figma, then Supabase. Security teams hated the sprawl. Engineers skipped connectors they needed because the auth flow was annoying. On June 18, the MCP project shipped Enterprise-Managed Authorization as stable, and for once the enterprise answer matches how IT already thinks about SaaS access.

I have been wiring MCP governance through gateways and tunnels in Databricks Unity AI Gateway patterns and preparing for stateless transport on July 28. EMA is the identity layer that should be in place before you delete sticky sessions. This post is the pilot checklist I run when a client says "we want MCP but our IdP team will not approve fifty OAuth apps."

What MCP EMA is (and what problem it solves)

Enterprise-Managed Authorization shifts the authorization decision from the individual user at click-time to the organization at provision-time. An admin maps MCP connectors to groups and roles in the IdP. When a user opens Claude Code or VS Code, the client obtains an Identity Assertion JWT from the IdP and exchanges it with the MCP authorization server for tokens scoped to what policy allows. The user does not see a separate OAuth redirect per server if policy already granted access.

The mechanism builds on Okta Cross App Access and the ID-JAG token profile. You do not need to memorize the acronyms to deploy it. You need to recognize that this is the same pattern IT uses for other enterprise SaaS: provision once, audit centrally, revoke in one place.

Who supports EMA today (June 2026)

Shipping status matters for pilots. As of the stable announcement:

• Clients: Anthropic (Claude, Claude Code, Cowork), VS Code IDE.
• IdP: Okta first; expect other enterprise IdPs to follow the same ID-JAG pattern.
• Connectors live: Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase.
• Slack: announced, not yet live in the initial connector set.

If your stack is Google Workspace-only today, you may need to wait for IdP expansion or run a parallel Okta pilot on the team that already uses it. Do not block the security design on vendor lag; design the group model now.

How EMA fits the July 28 stateless MCP spec

The 2026 MCP release candidate makes remote servers stateless: no sticky sessions, header-based routing, OAuth hardening across six proposals. EMA addresses a different pain point (who may connect), while stateless addresses operations (how connections scale). They compose. I want EMA group mappings documented before we rip out session stores, because incident response gets harder if identity and routing change simultaneously.

Recommended sequencing on engagements I lead: pilot EMA on one connector and one team in June, validate audit logs, expand connector set in July, migrate servers to stateless SDKs after July 28 GA window.

What EMA does not solve

EMA is authorization, not content validation. A user provisioned for Sentry MCP can still receive a poisoned error that tricks an agent into bad actions. Read Agentjacking for the content-trust half. EMA also does not replace least-privilege tool design inside each server. You still need typed tools and minimal projections from tool registry design.

Controls to pair with EMA

• Group-based connector allowlists (only Linear + GitHub for eng, only Figma for design).
• Separate read vs write tool policies per role where the server supports scoping.
• Central logging of MCP tool invocations through a gateway or host telemetry.
• Content-trust rules for observability and ticket feeds agents consume.
• Quarterly access reviews tied to IdP group membership, not forgotten OAuth tokens.

The EMA pilot checklist I run

1. 01
   Pick one team and one connector

   Linear or Atlassian are good first choices: high use, clear group boundaries, limited blast radius if misconfigured.
2. 02
   Map IdP groups to connector access

   Document which Okta groups grant which MCP servers. Avoid "all employees get all connectors" because it recreates OAuth sprawl with extra steps.
3. 03
   Validate exchange flow on Claude Code and VS Code

   Confirm ID-JAG exchange works for both hosts your engineers actually use. Dual-host validation catches policy gaps early.
4. 04
   Capture audit logs for 2 weeks

   You need answers to "who invoked which tool when" before expanding. If logs are insufficient, fix that before connector #2.
5. 05
   Run a revocation drill

   Remove a user from the group and confirm connector access dies within your expected IdP propagation window. If it does not, stop expanding.
6. 06
   Plan stateless migration in parallel

   Inventory sticky-session infrastructure destined for retirement post-July 28. EMA should be stable before you change routing.

Common enterprise mistakes with MCP auth

• Treating EMA as "turn on all connectors for everyone" to reduce tickets.
• Skipping revocation drills because provisioning worked once.
• Assuming IdP provisioning fixes agent content trust.
• Running stateless migration and EMA rollout in the same weekend.
• Ignoring VS Code vs Claude Code policy parity when teams split across hosts.

Conclusion

EMA is the enterprise MCP auth story that should have existed from day one. It replaces per-employee OAuth sprawl with IdP group provisioning and centralized revocation. Pilot it on one team, prove audit and revocation, then expand connectors while you still have runway before the July 28 stateless spec lands. Authorization and content trust remain separate problems. Solve both.

Sources: MCP Enterprise-Managed Authorization announcement at https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/.