If you're rolling out MCP (Model Context Protocol) inside an enterprise, the most painful part probably isn't connecting Servers — it's authorization: every employee has to walk through OAuth separately for every MCP Server, security teams have no way to audit centrally, and personal and work accounts easily get mixed up. The newly released Enterprise-Managed Authorization (EMA) extension from MCP exists to fix exactly this — it's already stable, and Anthropic, Microsoft, and Okta are all using it.

What EMA Solves

Standard MCP authorization is user-scoped: each user authorizes each Server individually. In enterprise settings that has three hard flaws:

• Every person must authorize every Server: onboarding means manually connecting one service after another
• Security teams can't govern centrally: access depends on whatever each user happened to authorize at the time, with no central control or auditing
• Work and personal accounts get conflated: there's no way to require corporate identity, so users can hook personal accounts into work tools

EMA makes the organization's IdP (identity provider) the authoritative decision-maker for MCP Server access. Admins define policy once, users sign in to the MCP host with their existing identity, and the IdP grants or denies access based on groups, roles, and conditional access rules.

The Core Mechanism: ID-JAG

EMA's underlying flow doesn't rely on per-server consent screens:

1. When the user signs in via SSO, the client obtains an Identity Assertion JWT Authorization Grant (ID-JAG) from the IdP
2. The client exchanges the ID-JAG for an access token with the MCP Server's authorization server
3. The user is never redirected to a per-server consent page

Three properties follow:

• Authorize once, inherited everywhere: when an admin enables a Server for the organization, users get it automatically, scoped to their existing groups/roles
• Centralized policy and auditing: access decisions live in the IdP admin console, with a single audit trail across all connectors
• No more personal/work account mixing: the interactive account-selection step is removed, lowering the risk of data accidentally flowing between personal and corporate accounts

Who Already Supports It

EMA's first wave of ecosystem support spans three sides:

Identity providers (IdPs)

• Okta is the first supported IdP; organizations can provision MCP access to supported Servers via Okta's Cross App Access (XAA)

Clients

• Anthropic has implemented EMA in its shared MCP layer; admins can authorize MCP Servers for users across Claude, Claude Code, and Cowork
• Visual Studio Code supports EMA directly inside the IDE

Server side

• Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already support EMA
• Slack and others are onboarding

How to Adopt It

If You're an Enterprise User

1. Confirm IdP support (currently Okta, via the XAA protocol)
2. Enable the target MCP Servers for your organization in the IdP admin console, scoped by group/role
3. Users automatically get the authorized connectors the first time they sign in to Claude / Claude Code / VS Code — no per-server OAuth needed

If You're an MCP Server Developer

Implement EMA following the official specification:

• Spec: Enterprise-Managed Authorization details the flows each party — client, server, authorization server — needs to implement
• Source and spec: the ext-auth repository holds the latest spec and supporting material
• Community: join the EMA Interest Group to discuss compatibility and iterate on the spec

When to Use EMA

EMA doesn't replace standard MCP authorization; as an extension, it gives enterprise scenarios a "zero-touch" option. For small-to-mid-size teams and individual users, the existing per-user OAuth flow is unaffected.

Primary sources:

• Enterprise-Managed Authorization: Zero-touch OAuth for MCP (official blog)
• Enterprise-Managed Authorization specification