MCP 的零接触 OAuth

零接触 OAuth / EMA 的范围与目标

• 将 OAuth 同意从单个终端用户转移到企业 IdP/IT 管理员。
• 主要面向员工账户，而非个人账户。
• 承诺的好处：
  • 集中控制哪些 MCP 服务器和应用可以访问企业数据。
  • “即开即用”的体验：当员工通过 SSO 登录 LLM 时，所有预先批准的 MCP 连接都已处于激活状态。
  • 更好的可审计性与合规性，尤其适用于受监管环境。
  • 有助于防止在存在企业账户时数据流向个人 SaaS 账户。

安全性、摩擦与同意之争

• 一些人认为当前 OAuth 的“摩擦”（提示、逐个应用同意）是特性，而不是缺陷。
• 担忧在于：代理可能被提示注入欺骗，在没有显式、按会话单独选择加入的情况下使用强大的 MCP（例如银行类 MCP）。
• 其他人回应说：
  • 细粒度控制以及按工具/按任务授权应由客户端/执行环境强制实施，而不应只依赖 LLM 提供商。
  • EMA 并没有从根本上改变 MCP 认证是按用户而不是按会话进行这一事实。
• 还有人担心员工会失去对代表自己连接了什么的可见性和责任感。

企业身份 vs 消费者身份

• EMA 被认为与企业现实高度契合：
  • 公司实际上“拥有”身份，并且可以集中撤销或重塑访问权限。
  • 适合 IdP 断言是主要信任锚的环境。
• 几位评论者认为，这种模型对消费者身份来说存在问题，因为：
  • 每个应用直接拥有用户账户。
  • 没有任何单一 IdP 可以安全地充当通用委托授权机构。

MCP vs Skills / 其他集成模式

• 关于 MCP 与“skills”/基于 CLI 的工具的争论仍在继续：
  • 支持 MCP 的观点：来自服务器的语义描述、工具搜索、更好的审计轨迹、标准化部署、无需任意代码执行。
  • 批评者指出令牌暴露风险，并认为可以通过工具/skills 加上代理或网关实现类似目标。
• 一些人认为 MCP 越来越像一个带共享认证的“应用框架”，而不仅仅是一个协议。

实现与标准问题

• 底层机制（ID-JAG）并非 MCP 特有，也可用于 CLI 或其他 OAuth 客户端。
• 动态客户端注册是一个痛点；许多 IdP（例如某些企业目录）对其支持不佳，迫使人们采用代理或预注册客户端等变通方案。
• 围绕任务级授权、多跳委托以及弱化能力型令牌的工作仍在推进，但细节仍在演进之中，而且有些不够清晰。