Hacker News Best

Zero-Touch OAuth for MCP

8.5内容质量

TL;DR · AI 摘要

企业可通过零接触OAuth实现MCP服务器集中授权,提升管理效率与用户体验。

核心要点

  • 企业可通过身份提供商集中管理MCP服务器访问权限。
  • 用户首次登录即可自动连接所需服务器,无需逐个授权。
  • EMA已被Anthropic、Microsoft等公司采用,提升企业部署效率。

结构提纲

按章节快速跳转。

  1. 当前MCP授权模型在企业环境中存在高摩擦、缺乏集中控制等问题。

  2. EMA通过企业身份提供商实现集中授权,用户首次登录即可自动连接服务器。

  3. 用户通过单点登录获取JWT授权,无需逐个服务器授权。

  4. AnthropicMicrosoftOkta等公司已采用EMA,提升企业部署效率。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 企业授权的零接触OAuth解决方案
    • EMA的优势
      • 集中管理
      • 用户零配置
      • 提升部署效率
    • EMA的工作机制
      • 通过IdP获取JWT授权
      • 单点登录自动连接服务器

金句 / Highlights

值得收藏与分享的关键句。

#OAuth#MCP#企业授权#身份提供商
打开原文

企业托管授权:MCP 的零接触 OAuth | Model Context Protocol 博客

主页

»

文章

企业托管授权:MCP 的零接触 OAuth

Model Context Protocol 的企业托管授权扩展现已稳定,使组织能够通过其身份提供商集中地为 MCP 服务器提供访问权限,从而让用户在首次登录时无需每个应用的 OAuth 即可连接服务器。

2026 年 6 月 18 日 · 5 分钟 · Paul Carleton(核心维护者)

目录

  • 每个用户的授权摩擦较大
  • 授权一次,处处继承
  • 早期采用者
  • 参与进来
  • 致谢

企业托管授权扩展现已稳定。组织可以集中管理 MCP 服务器的授权,终端用户可以通过一次登录访问所有连接的 MCP 服务器。该扩展正在被 Anthropic、Microsoft、Okta 和越来越多的 MCP 服务器采用。

企业托管授权(EMA)扩展现已稳定。我们从社区了解到,授权和来自连接的 MCP 服务器的重复同意提示是企业在管理连接时遇到的最大痛点之一。此扩展有助于解决这一问题。

EMA 允许组织通过其信任的身份提供商集中控制对 MCP 服务器的访问。对于终端用户来说,这意味着零接触设置:在首次登录时,他们需要的 MCP 服务器会自动连接,无需每个应用的 OAuth,也不需要进行一次性配置。

每个用户的授权摩擦较大 #

标准的 MCP 授权模型是为用户范围设计的,并绑定到传统的交互式授权惯例。虽然这可能在更一般的消费者场景中表现良好,其中个人决定哪些内容可以接触他们的数据,但这并不适合企业部署:

  • 每个员工都必须单独授权每个服务器:入职意味着手动连接一个又一个服务。
  • 安全团队无法强制执行一致的策略:访问权限是每个用户授权的,没有中央控制或审计跟踪。
  • 工作和个人账户混淆在一起:没有方法强制要求使用公司身份,因此用户可以将个人账户连接到工作工具。

这些因素的结合减缓了 MCP 的采用,并促使人们转向脆弱的变通方法。由于没有统一的标准来保存共享的授权状态,每个人都会发明自己的定制解决方案。数据和工具是可用的,但每个用户的授权税使大多数人关闭了它们。

授权一次,处处继承 #

企业托管授权使组织的 IdP 成为 MCP 服务器访问的权威决策者。管理员只需定义一次策略,用户就可以使用现有的身份认证到 MCP 主机。IdP 可以根据组成员资格、角色和条件访问规则授予或拒绝访问。

在幕后,客户端在单点登录期间从 IdP 获取 Identity Assertion JWT 授权授予(ID-JAG),并将其交换为 MCP 服务器授权服务器的访问令牌。用户永远不会被重定向到每个服务器的同意屏幕。这个流程产生了三个特性:

  • 授权一次,处处继承:管理员为组织启用服务器。用户会自动获得它,范围限定在他们已有的组和角色中。
  • 集中式策略和审计:访问决策位于 IdP 管理控制台,所有连接器都有一条统一的可审计记录。
  • 消除个人账户与企业账户的混淆:通过移除交互式账户选择步骤,可以更轻松地防止数据因误操作或被入侵而从个人账户流向企业账户。

我们认为这是 MCP 在企业环境中全新的基准。当用户登录时,他们的客户端应直接连接到他们被授权使用的工具和数据,中间无需任何额外步骤。

早期采用者 #

此次发布汇集了三个紧密合作的群体,共同推动了该功能的实现:

  • 身份提供商:Okta 是首个支持的身份提供商。使用 Okta 的组织可以通过任何支持的客户端,利用 Okta 的跨应用访问(XAA)功能,为支持的服务器提供 MCP 访问权限。
  • 客户端:Anthropic 已在其共享的 MCP 层中实现了该扩展,应用于 Claude。管理员可以为 Claude、Claude Code 和 Cowork 中的用户授权 MCP 服务器。此外,Visual Studio Code 也在 IDE 中增加了对 EMA 的支持。
  • 服务器:Asana、Atlassian、Canva、Figma、Granola、Linear 和 Supabase 现在都支持 EMA,Slack 等也在积极添加支持。

我们期待更多的身份提供商、客户端和服务器采用企业托管认证,以减少与授权相关的疲劳感,并显著提升实施者的安全性和可观测性。

“MCP 的发展势头令人惊叹,但随着我们向互联的人工智能工作环境迈进,安全不能被忽视。通过将跨应用访问协议嵌入到 MCP 中,作为企业托管授权扩展,我们使身份成为一个集中的治理平面,为安全团队提供严格的合规控制,同时为用户带来无缝且安全的体验。” —— Okta 身份标准总监 Aaron Parecki

“Figma 的 MCP 将代码和画布的力量结合在一起,使团队能够更快地前进,探索更多可能性,并推出具有特色的优秀产品。随着 MCP 的采用率增加,XAA 使企业能够更安全地扩展其 MCP 部署,而不会影响团队的效率。” —— Figma 工程副总裁 Devdatta Akhawe

“只需登录一次,所有 MCP 连接器就会自动设置,这感觉非常神奇。” —— Linear 工程主管 Tom Moor

参与进来 #

与其他所有 MCP 扩展、功能和增强功能一样,我们欢迎您的意见。我们鼓励客户端、服务器和身份平台查看扩展规范,并在他们的产品中添加对新标准的支持:

  • 阅读要求:企业托管授权页面记录了客户端、服务器和授权服务器的流程。
  • 源码和草案规范:请查看 ext-auth 仓库和 EMA 的草案规范,了解 EMA 的最新发展以及任何可以帮助您入门的支持材料。

如果您有兴趣讨论该扩展、分享兼容性报告或对该扩展进行迭代,请加入 EMA 兴趣小组。

致谢 #

企业托管授权是 MCP 社区共同努力的结果:SEP-990 的作者、ext-auth 仓库的维护者,以及早期测试实现并推动规范向前发展的身份和 MCP 提供商。感谢所有为该工作做出贡献的人。