如果你在企业里推 MCP（Model Context Protocol），最痛的可能不是接 Server，而是授权：每个员工要对每个 MCP Server 单独走一遍 OAuth，安全团队没法统一审计，个人账号和企业账号还容易混在一起。MCP 官方刚发布的 Enterprise-Managed Authorization（EMA）扩展就是来解决这个问题的——它已经 stable，Anthropic、Microsoft、Okta 都在用。

EMA 解决了什么

标准 MCP 授权是 user-scoped 的，每个用户对每个 Server 单独授权。这在企业场景下有三个硬伤：

• 每人要授权每个 Server：入职要把一个又一个服务手动连一遍
• 安全团队无法统一管控：访问权限取决于每个用户当时授权了什么，没有中央控制和审计
• 工作账号与个人账号混淆：没法强制要求企业身份，用户可以把个人账号连到工作工具

EMA 把组织 IdP（身份提供商）变成 MCP Server 访问的权威决策方。管理员定义一次策略，用户用既有身份登录 MCP host，IdP 根据组、角色、条件访问规则授予或拒绝访问。

核心机制：ID-JAG

EMA 的底层流程不依赖 per-server consent screen：

1. 用户 SSO 登录时，客户端从 IdP 获取一个 Identity Assertion JWT Authorization Grant（ID-JAG）
2. 客户端用 ID-JAG 向 MCP Server 的授权服务器换取 access token
3. 用户永远不会被重定向到 per-server consent 页面

由此带来三个性质：

• 授权一次，处处继承：管理员为组织启用一个 Server，用户自动获得，按其已有的组/角色范围限定
• 集中策略与审计：访问决策都在 IdP 管理后台，跨所有连接器一条审计轨迹
• 消除个人/企业账号混用：去掉了交互式账号选择步骤，降低数据在个人与企业账号间误流的风险

谁已经支持

EMA 的首批生态由三方组成：

身份提供商（IdP）

• Okta 是首个支持的 IdP，组织可通过 Okta 的 Cross App Access（XAA）向受支持的 Server provision MCP 访问

客户端

• Anthropic 已在其共享 MCP 层实现 EMA，管理员可跨 Claude、Claude Code、Cowork 为用户授权 MCP Server
• Visual Studio Code 已在 IDE 内直接支持 EMA

Server 端

• Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 已支持 EMA
• Slack 等正在接入

如何接入

如果你是企业用户

1. 确认 IdP 支持（当前是 Okta，通过 XAA 协议）
2. 在 IdP 管理后台为组织启用目标 MCP Server，按组/角色限定范围
3. 用户首次登录 Claude / Claude Code / VS Code 时自动获得已授权的连接器，无需逐个 OAuth

如果你是 MCP Server 开发者

参考官方规范实现 EMA：

• 规范文档：Enterprise-Managed Authorization 详细描述了 client、server、authorization server 各方需要实现的流程
• 源码与 spec：ext-auth 仓库 包含最新 spec 和支持材料
• 社区：加入 EMA Interest Group 讨论兼容性、迭代 spec

何时该用 EMA

EMA 不替代标准 MCP 授权，而是作为扩展，给企业场景一个"零接触"选项。对中小团队或个人用户，原有 per-user OAuth 流程不受影响。

一手来源：

• Enterprise-Managed Authorization: Zero-touch OAuth for MCP（官方博客）
• Enterprise-Managed Authorization 规范