MCP 认证终于不折腾了：Zero-Touch OAuth 上线，企业级部署的最后一块拼图

昨天刷新 Hacker News 的时候看到一条帖子，200 多分，标题是 "Zero-Touch OAuth for MCP"。点进去一看，MCP 官方博客发了篇文章，说 Enterprise-Managed Authorization（EMA）扩展正式稳定了。

我的第一反应是：终于。

如果你在公司里部署过 MCP 服务器，你一定懂我在说什么。之前那个认证流程，简直反人类。每个员工要对每个 MCP 服务器单独授权一次，10 个人用 5 个服务器，就是 50 次 OAuth 跳转。新员工入职？先花半天点授权按钮。安全团队？别问了，审计日志散落在各个服务里，想查谁访问了什么根本拼不起来。

这次 EMA 的思路很直接：让公司的身份提供商（IdP）统一管认证，用户登录一次，所有授权过的 MCP 服务器自动连上。听起来理所当然对吧？但 MCP 花了快一年才把这事儿搞利索。

之前到底有多痛

先说说之前的认证模型有什么问题。MCP 最初的授权设计是面向个人用户的，走的是标准 OAuth 2.0 流程。你在 Claude Desktop 里加一个 MCP 服务器，它弹出一个授权页面，你点同意，完事。

这个方案在个人场景下没问题。你用你的 GitHub 账号连你的 MCP 服务器，很清晰。

但企业环境完全是另一回事。

第一个问题：每个用户每个服务器都要单独授权。 假设你的团队有 20 个人，公司配了 6 个 MCP 服务器（GitHub、Jira、Slack、Figma、数据库、内部工具），那就是 120 次 OAuth 授权。新来的同事第一天不是在熟悉业务，是在点"同意授权"。

我之前帮一个朋友的公司搭 MCP 环境，他跟我说："每次有新人入职我都要手把手教他们点一遍授权，比教他们用 Git 还累。" 这句话我记到现在。他们公司 30 多个开发，每人要连 8 个 MCP 服务器，光授权就要搞 240 次。后来他们写了个内部文档，把每个服务器的授权步骤截图放进去，十几页。这不是在用工具，这是在做客服。

第二个问题：安全团队管不了。 授权是用户自己做的，安全团队没法集中控制谁能访问什么。你想设置一个"只有开发组能连生产数据库 MCP"的策略？没有这个能力。每个人凭自己的账号授权，跟公司身份体系完全脱节。

有个更尴尬的场景：有人离职了，你得手动去每个 MCP 服务器把他的授权取消。万一漏了一个呢？他的 token 可能还能用。这种事安全审计的时候查出来，负责人的脸色不会好看。

第三个问题：个人账号和企业账号混在一起。 因为 OAuth 跳转的时候用户可以选账号，有人不小心用个人 GitHub 账号连了公司的 MCP 服务器，代码仓库权限就串了。不是故意的，但后果可能很严重。

第四个问题：授权弹窗疲劳。 这个不只是 MCP 的问题，所有基于 OAuth 的系统都有。但 MCP 把这个问题放大了，因为你要连的服务器特别多。每个服务器弹一次，弹到最后用户根本不看内容直接点"同意"。这时候如果弹出一个钓鱼页面，用户也会点同意。

之前社区里有人提议用 API Key 代替 OAuth，简单粗暴。但 API Key 的问题是没有跟身份绑定，泄露了就是泄露了，没有撤销粒度。也有人建议用 Service Account，但那就回到了"怎么管理 Service Account 的凭证分发"的问题。

所以 EMA 的出现，本质上是把所有这些零散的、各自为政的认证方式统一收口到公司的身份提供商。不是发明新轮子，是把已有的轮子装对位置。

EMA 怎么解决的

Enterprise-Managed Authorization 的核心思路就一句话：把 MCP 服务器的访问策略收到公司身份提供商那里统一管理。

技术上怎么实现的呢？流程大概是这样的：

管理员在公司的 IdP（比如 Okta）后台配置策略：哪些用户/组可以访问哪些 MCP 服务器
用户打开 Claude Desktop 或者 VS Code，用公司 SSO 登录
登录过程中，客户端从 IdP 拿到一个 Identity Assertion JWT Authorization Grant（简称 ID-JAG）
客户端用这个 ID-JAG 去 MCP 服务器的授权服务换 access token
用户不需要再跳转到每个服务器的授权页面，token 直接拿到了

整个过程对用户来说就是"登录了一下，所有工具都连好了"。Zero-Touch，名副其实。

技术细节：ID-JAG 是什么

EMA 的核心是 ID-JAG（Identity Assertion JWT Authorization Grant），它是 OAuth 2.0 的一个扩展。目前还在 IETF 草案阶段（draft-ietf-oauth-identity-assertion-authz-grant），但已经有实际产品在用了。

跟传统的 OAuth 授权码流程对比一下：

传统流程：

code

1	`用户点击"连接 GitHub MCP"`
2	`→ 跳转到 GitHub 授权页面`
3	`→ 用户登录 GitHub`
4	`→ 用户点"同意授权"`
5	`→ GitHub 回调到 MCP 客户端，带授权码`
6	`→ 客户端用授权码换 access token`

每个 MCP 服务器走一遍这个流程。

EMA 流程：

code

1	`用户打开 Claude Desktop`
2	`→ 用公司 SSO 登录（一次性）`
3	`→ IdP 签发 ID-JAG（包含用户身份、组、角色）`
4	`→ 客户端自动用 ID-JAG 去各 MCP 服务器换 token`
5	`→ 用户直接开始用`

中间少了 N 个跳转和 N 次手动同意。

ID-JAG 本质上是一个 JWT，里面包含了：

用户身份：这个人在公司的 IdP 里是谁
组和角色：属于哪些组，有什么角色（比如 developer、admin）
签发者：是哪个 IdP 签发的（用于验证签名）
过期时间：token 的有效期

MCP 服务器拿到这个 JWT 之后，做的事情就是：

验证 JWT 的签名（通过 IdP 的公钥，确保没被篡改）
检查签发者是不是受信任的 IdP
根据 JWT 里的组和角色信息，决定给这个用户什么权限
签发 access token

关键的安全设计：

JWT 签名验证：MCP 服务器必须验证 ID-JAG 的签名，确保它确实来自受信任的 IdP。这防止了伪造身份的攻击。
scope 绑定：access token 的 scope 由 IdP 的策略决定，不是用户自己选的。管理员说你只能读，你就只能读。
无交互授权：用户不需要点"同意"按钮，因为策略是管理员预先配置好的。这减少了钓鱼攻击的向量（攻击者没法通过伪造授权页面获取 token）。

不过有个地方我觉得还得观察：ID-JAG 还是 IETF 草案，没有正式成为 RFC。虽然 Okta 和 Anthropic 已经在用了，但标准可能会变。如果你要实现这个，得做好跟着 spec 变动的准备。

谁在用

EMA 刚宣布稳定，但早期采用者的阵容已经很豪华了。

身份提供商方面，Okta 是第一个支持的。Okta 把自己的 Cross App Access（XAA）协议嵌入了 MCP 的 EMA 扩展。用 Okta 做公司身份管理的团队，现在可以直接在 Okta 后台配置 MCP 服务器的访问策略。

Okta 的身份标准总监 Aaron Parecki 说了一句话我觉得总结得很好："随着我们走向互联的 AI 工作流，安全不能是事后才考虑的事。把 XAA 协议嵌入 MCP 的 EMA 扩展，是把身份变成集中治理层。"

客户端方面，Anthropic 在 Claude 的共享 MCP 层里实现了 EMA。管理员授权一次，Claude、Claude Code、Cowork 三个产品都能用。VS Code 也在 1.123 版本加了 EMA 支持，直接在 IDE 里就能用。

VS Code 支持 EMA 这个事情对我触动挺大的。VS Code 是开发者用得最多的 IDE，它支持 EMA 意味着大部分开发者不需要换工具就能用上零接触认证。

服务器方面，Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase 都已经支持了。Slack 在路上。

Figma 的 VP of Engineering 说："XAA 让企业能安全地扩展 MCP 部署，不会拖慢团队。" Linear 的工程负责人更直接："登录一次，所有 MCP 连接器自动配置好，这体验很魔幻。"

说实话这个速度比我预想的快。MCP 从发布到现在也就一年多，认证这块从"能用就行"到"企业级可用"，进展不慢。

跟其他方案的对比

在 EMA 出来之前，企业部署 MCP 一般有几种认证方案，各有各的问题。

方案一：共享 API Key 把 API Key 写在环境变量或者配置文件里，所有用户共用一个 Key。

优点：配置简单，不需要 OAuth 流程。缺点：没法区分用户，Key 泄露影响所有人的数据，没法审计"谁做了什么"。结论：个人项目可以用，企业环境不行。

方案二：Service Account + 分发工具 创建一个 Service Account，用公司的密钥管理工具（比如 HashiCorp Vault）把凭证分发给用户。

优点：可以统一管理凭证的生命周期。缺点：搭建和维护成本高，而且本质上还是在分发"凭证"，不是在做"身份认证"。结论：适合大公司，小团队搞不起。

方案三：每个用户自己的 OAuth 就是 EMA 之前的默认方案。

优点：安全，每个用户用自己的身份。缺点：上面说的那些痛点——授权太多、管不了、账号混在一起。结论：能用，但痛苦。

方案四：EMA 让 IdP 统一管。

优点：安全 + 集中管理 + 用户无感。缺点：依赖 IdP 支持（目前主要是 Okta），ID-JAG 标准还在草案阶段。结论：目前最好的企业方案，但生态还在建设中。

对小团队来说，可能方案一或者方案三够用了。但只要团队超过 10 个人、MCP 服务器超过 3 个，EMA 的价值就很明显了。

对 MCP 服务器开发者的影响

如果你在开发 MCP 服务器，EMA 对你意味着两件事。

第一，如果你的服务器面向企业客户，EMA 支持会是一个加分项。 企业客户在选型的时候，认证方式是一个重要考量。如果你支持 EMA，客户可以直接把你的服务器加入他们的 IdP 策略，不需要每个用户单独注册账号。这个体验差异很大。

接入 EMA 的话，你需要做的事情大概是：

支持 ID-JAG 作为 Authorization Grant 类型
配置受信任的 IdP 列表（JWKS 端点）
实现 JWT 验证逻辑
根据 JWT 里的组和角色信息映射到你自己的权限系统

听起来不少，但如果你已经在做 OAuth 2.0，增量工作量其实可控。

第二，你的权限模型需要更精细。 EMA 解决的是"谁能连你的服务器"，但"连上之后能做什么"还是你自己的事。如果你的服务器只有一个全有或全无的权限，EMA 帮不了太多。你需要至少支持读写分离、资源级别的权限控制。

我之前写过一篇 MCP 服务器安全的文章，当时提到了认证和授权是个大问题。现在 EMA 出来了，认证这块的问题至少解决了一大半。剩下的是细粒度权限控制，比如"这个用户只能读数据不能写"、"这个用户只能访问特定项目的资源"，这些还得靠各个 MCP 服务器自己实现。

还有什么没解决的

EMA 解决了"统一认证"的问题，但 MCP 的安全故事还远没有结束。

细粒度权限：EMA 管的是"谁能访问哪个服务器"，但"在服务器里能做什么"还是靠服务器自己控制。比如你连了 GitHub 的 MCP 服务器，EMA 可以控制你能不能连，但你能不能 push 代码、能不能删 repo，这些是 GitHub MCP 服务器自己的权限系统管的。

多租户隔离：如果一个 MCP 服务器服务多个客户，怎么确保 A 公司的数据不会泄露给 B 公司？EMA 提供了身份信息，但数据隔离还是得服务器自己做。

离线场景：EMA 依赖在线的 IdP 验证。如果用户断网了，或者 IdP 挂了，怎么办？这个 spec 里好像没有明确的降级方案。不过说实话，在 AI 工具的场景下，离线本身就不太多见。

审计日志的标准化：虽然 IdP 集中了认证日志，但 MCP 服务器的使用日志（调用了哪个工具、传了什么参数）还是分散在各个服务里。想要一个统一的审计视图，还得自己搭。

这些问题不是说 EMA 做得不好，而是认证只是安全的一部分。有了 EMA，至少认证这块的地基打好了，后面可以在上面盖更复杂的安全策略。

常见问题

写到这里，我觉得有些问题大家可能会问，提前回答一下。

Q：不用 Okta 能用 EMA 吗？

目前不行。EMA 需要一个支持 ID-JAG 的身份提供商，目前只有 Okta 通过 Cross App Access 协议支持。Azure AD、Google Workspace 这些暂时还没有官宣支持 EMA，但考虑到 Anthropic 和 Microsoft 的合作关系，VS Code 都已经支持了，Azure AD 的支持应该不会太远。

如果你的公司既不用 Okta 也不急着上企业级 MCP，可以先等等。如果你急着用，可以考虑用 Okta 的免费试用先体验一下 EMA 的流程。

Q：EMA 跟普通的 SSO 有什么区别？

普通的 SSO 只解决"登录"的问题——你用公司账号登录 Claude Desktop，但登录之后要连哪些 MCP 服务器，还是得一个一个配。EMA 在 SSO 的基础上加了"授权继承"——你登录的同时，管理员配好的 MCP 服务器自动连上，不需要额外操作。

可以理解为：SSO 是"用一个账号登录所有应用"，EMA 是"用一个账号登录并自动获得所有授权"。

Q：EMA 会影响 MCP 服务器的性能吗？

理论上不会有明显影响。ID-JAG 的验证是一个 JWT 签名验证操作，用的是标准的 JWS 库，计算量很小。而且 access token 一旦拿到，后续的请求走的是普通的 Bearer Token 认证，跟 EMA 没关系。

唯一可能有影响的是首次连接的时候，因为要走一次 SSO + ID-JAG 交换流程，可能比直接用 API Key 慢几百毫秒。但这是在登录阶段，不是在每次请求阶段，所以实际使用中感知不到。

Q：个人开发者需要关注 EMA 吗？

如果你只是自己用 MCP，不需要关注。EMA 是给企业环境设计的。但了解一下没坏处，万一以后跳槽到大公司，知道这个东西的存在能少走弯路。

而且 ID-JAG 这个 IETF 草案本身挺有意思的，它代表了一种趋势：把身份验证从"应用层面"提升到"平台层面"。不只是 MCP，以后其他需要跨应用认证的场景可能也会用类似的方案。

一个真实场景：30 人团队的 MCP 部署

让我用一个具体的例子说明 EMA 的价值。

假设你是一个 30 人的技术团队的负责人，要给全公司部署 MCP。你选了 6 个 MCP 服务器：GitHub、Jira、Slack、Figma、PostgreSQL、内部 API 网关。

没有 EMA 的时候：

每个员工需要对 6 个服务器分别做 OAuth 授权 → 30 × 6 = 180 次授权操作
新员工入职要花 30-60 分钟点授权按钮
有人离职了，你需要手动去 6 个服务器分别取消他的授权
安全审计的时候，你需要从 6 个不同的地方收集日志
有人用个人账号连了公司服务器，你发现的时候已经过了两周

有 EMA 的时候：

管理员在 Okta 后台配置一次策略（30 分钟）
员工打开 Claude Desktop，用公司 SSO 登录，6 个服务器自动连好
有人离职了，在 Okta 里禁用他的账号，所有 MCP 访问自动撤销
安全审计直接看 Okta 的日志，一目了然
个人账号混入的可能被消除了，因为认证走的是公司 SSO

这个对比不需要我多说什么了吧。

跟 MCP 整体发展的关系

MCP 这个协议从发布到现在，争议一直不少。有人说它是"AI 时代的 HTTP"，有人说它是"过度设计的中间层"。我个人的看法是：MCP 本身就是一个连接协议，好不好用取决于生态。

EMA 的发布让我对 MCP 的信心增加了一些。原因很简单：如果 MCP 只是给个人开发者玩玩的玩具，Anthropic、Microsoft、Okta 这些大厂不会投入资源去做企业级认证。它们愿意做，说明企业客户确实在用 MCP，而且认证痛点是真实的。

想想看，从 MCP 发布到现在，生态发展得确实快。协议本身在迭代，认证在完善，服务器越来越多，主流 IDE 都支持了。这不像是一个会昙花一现的项目。

不过我也有一些担心。MCP 的 spec 演进很快，新扩展一个接一个。EMA 刚稳定，可能又有新的扩展在路上。对于做 MCP 服务器的开发者来说，追 spec 是一个持续的成本。希望 Anthropic 能控制好节奏，不要让社区疲于奔命。

另外，EMA 的设计没有过度创新。它复用了 OAuth 2.0 的框架，ID-JAG 是 IETF 标准化的工作，Okta 的 XAA 也是已有的协议。这种"站在已有标准上做事"的方式比"发明一套全新的认证系统"靠谱多了。我见过太多项目在认证上自创一套，最后都维护不下去。

实际部署中要注意的几个坑

EMA 听起来很美好，但实际部署的时候还是有一些地方需要注意。

坑一：IdP 策略配置错误会导致所有人连不上。 这是管理员最怕的事。你在 Okta 后台配策略的时候，如果用户组选错了，或者 MCP 服务器的回调 URL 填错了，所有人登录之后都会发现 MCP 服务器连不上。而且报错信息通常不太友好，用户只会看到"连接失败"，不会告诉你是因为策略配错了。

建议：先用一个测试组、一个 MCP 服务器做 pilot，确认流程跑通了再扩大范围。

坑二：token 刷新的时序问题。 ID-JAG 换来的 access token 是有过期时间的。过期之后客户端需要重新获取 token。如果客户端的 token 刷新逻辑有问题，用户可能会在用着用着的时候突然断连。这个在 Claude Desktop 和 VS Code 里应该已经处理好了，但如果你自己实现客户端，要注意 token 生命周期管理。

坑三：多 IdP 场景。 如果你的公司有多个身份提供商（比如一个 Okta 管员工，一个 Azure AD 管外包），EMA 的配置会复杂不少。目前 spec 里支持多 IdP，但实际操作中怎么配、优先级怎么定，文档还不够详细。

坑四：用户缓存的旧 token。 如果用户之前用传统 OAuth 授权过某个 MCP 服务器，切换到 EMA 之后，旧的 token 可能还在本地缓存里。这可能导致权限不一致——旧 token 有更高的权限，EMA 的新 token 权限更小，但客户端还在用旧的。切换认证方式的时候，最好让用户清一下本地的 token 缓存。

这些坑都不是大问题，但如果你不提前知道，部署的时候可能会踩到。提前了解这些，部署过程会顺畅很多。

实际怎么用

如果你想在自己的环境里试试 EMA，大概的步骤是这样的。

前提条件：

一个支持 EMA 的身份提供商（目前主要是 Okta）
一个支持 EMA 的 MCP 客户端（Claude Desktop 或 VS Code 1.123+）
一个支持 EMA 的 MCP 服务器（Asana、Figma、Linear 等）

配置流程：

在 Okta 后台创建一个 Cross App Access 策略
把你要用的 MCP 服务器添加到策略里，配置允许访问的用户组
在 Claude Desktop 或 VS Code 里登录公司 SSO 账号
客户端自动发现并连接到策略里配置的 MCP 服务器
用户打开工具，直接开始用，不需要额外配置

具体的 Okta 配置步骤可以参考他们的官方文档。Claude 这边，管理员在 Anthropic 的管理后台配置 MCP 服务器列表就行。VS Code 的话，在 settings.json 里配置 EMA 相关的字段。

说实话，如果你的公司已经在用 Okta 做 SSO，接入 EMA 的成本不高。主要的工作量在管理员那边，用户基本无感。

如果你的公司不用 Okta，那暂时只能等其他 IdP 支持了。Azure AD、Google Workspace 这些应该也在路上，但目前还没有官宣。如果你急着用，可能得考虑临时切换到 Okta，或者等一等。

说说我的看法

总的来说，EMA 是 MCP 生态的一个重要里程碑。它把 MCP 从"个人工具"推向了"企业基础设施"。对普通用户来说，最直接的感受就是：在公司用 AI 工具的时候，不用再一个个点授权了。

我觉得 MCP 最聪明的地方在于，它没有试图自己解决所有问题。认证交给 IdP，权限交给各个服务器，MCP 只负责定义"怎么连接"。这种分工明确的架构比"一个协议包办一切"要健康得多。

后面我会继续关注 MCP 的发展，特别是细粒度权限和多租户隔离这块。有啥新进展再写。

另外，MCP 官方的 EMA Interest Group 已经成立了，如果你对这个方向感兴趣，可以去参加。spec 仓库在 GitHub 上是公开的（modelcontextprotocol/ext-auth），可以提 issue 和 PR。这种早期参与标准制定的机会其实挺难得的，特别是如果你的公司正在用 MCP 或者你在做 MCP 服务器的话。

对了，如果你也在公司推 MCP，遇到过认证相关的坑，欢迎评论区聊聊。我特别想知道大家在实际部署中遇到了什么问题。尤其是非 Okta 的身份提供商，有没有人试过其他方式实现类似 EMA 的效果？如果有，分享一下方案，我挺好奇的。

本文写于 2026 年 6 月 19 日。EMA 扩展于 2026 年 6 月 18 日正式宣布稳定。参考来源：MCP 官方博客、EMA 扩展规范、Okta Cross App Access 文档、VS Code 1.123 更新日志。*