MCP协议强制要求OAuth 2.1：AI Agent身份验证洗牌

过去两年，"AI 智能体认证"意味着选择你喜欢的 OAuth 提供商、接入一个 token，然后听天由命。这种随意态度在 2026 年 7 月 28 日戛然而止。Model Context Protocol（MCP）——这个决定智能体如何与工具通信的规范——发布了自发布以来最大的修订版，而在 session-model 重写中隐藏着一个更重大的变化：MCP 服务器现在被正式要求像 OAuth 2.1 资源服务器一样运作。发现机制、token 受众绑定、动态客户端注册——所有这些从"有则更好"变成了"必须实现"。

这一处规范变更将一个用户体验决策变成了基础设施决策，这也是为什么三家曾经销售着几乎可互换的登录框的公司，如今对同一个问题给出了截然不同的答案：一款自主运行的软件如何证明它是谁，它在为谁行事？

本文对比了 WorkOS AuthKit、Auth0 for AI Agents（Okta）和 Stytch Connected Apps——这三家将自己定位为 MCP 兼容身份提供商的公司——以及一个经常与之混淆的第四类：Composio，它解决的是一个相关但本质不同的问题。如果你现在正在选择其中之一，差异比营销页面所呈现的更重要。

为什么这是一个当下需要做的决策，而非假设

这次转变背后的数据并非推测。到 2025 年末，MCP 的 Python 和 TypeScript SDK 合并月下载量已突破 9700 万次，距离 Anthropic 发布该协议还不到 18 个月。2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux 基金会旗下新成立的 Agentic AI Foundation——这种治理举措通常是针对人们预期会依赖十年的基础设施才会采取的。Gartner 预测，到 2026 年底，最多 40% 的企业应用将附带一个集成的、任务特定的 AI 智能体，而一年前这一比例还不到 5%。

这样的规模改变了"身份"的含义。云安全联盟（Cloud Security Alliance）2026 年 5 月的白皮书指出，在普通企业中，非人类身份与人类用户的比例达到 45:1，在云原生环境中攀升至 144:1。这种增长的大部分现在都来自智能体，而非过去主导这一计数量的服务账户和定时任务。而且与服务账户不同，智能体执行的并非开发者在发布前审查过的固定代码路径——它在运行时推理，决定调用哪些工具，并且可能因日期不同而从相同提示词中产生不同的操作序列。你无法用审计微服务权限集的方式来审计它，因为智能体在特定运行中使用的权限集在配置时是无法完全预知的。

在 2026 年 7 月 28 日之前，用一家供应商自己的回顾话说，MCP 的答案是"自带 token"。2025-11-25 版规范引入了 OAuth 2.1 作为可选项；2026-07-28 版规范则将其变为必选项。MCP 服务器现在必须实现 OAuth 2.0 Protected Resource Metadata（RFC 9728），以便客户端能够自动发现正确的授权服务器；MCP 客户端必须实现 Resource Indicators（RFC 8707），以便为一个 MCP 服务器签发的 token 无法被重放攻击另一个 MCP 服务器——这封堵了一个在旧规范下理论上可利用的 token 混淆漏洞。动态客户端注册也不再是默认路径；新规范优先采用 OAuth Client ID Metadata Documents（CIMD），DCR 被降级为可选的回退方案。

这一切都不是抽象的合规细节。如果你现在要启动一个远程 MCP 服务器，无论你的认证层是开箱即用地满足这些 MUST 级别要求，还是需要自己附加上去，这将决定你是在一个 sprint 内交付，还是花一个季度从规范文本开始构建一个授权服务器。

每个选项实际上是什么

值得一开始就区分清楚，因为这四个名字尽管做的是不同的工作，却在比较讨论中被混为一谈。

WorkOS AuthKit 是一家自 2020 年起就将自己定位为独立企业身份层的产品的娘家，你可以将它附加到一个应用上，而无需替换你的用户数据库。AuthKit 可以作为 OAuth 2.1 授权服务器，直接针对官方 MCP SDK 为 MCP 服务器服务，它与 WorkOS 剩余的技术栈并列存在：Enterprise SSO、SCIM 目录同步、供 IT 团队自助配置 SSO/SCIM 连接的 Admin Portal、审计日志，以及 Fine-Grained Authorization（FGA）。FGA 这个组件对智能体来说最为关键——它将权限细化到单个工具而非整个服务，因此一个智能体可以被授权调用 calendar.read 而无需继承日历 API 的全部访问权限。

Auth0 for AI Agents 来自 Okta，是这家老牌厂商在现有 OAuth 2.0/OIDC 平台之上给出的答案，而非一条新的产品线。"Auth for MCP"于 2025 年 11 月退出早期访问阶段，并于 2026 年 5 月 6 日正式发布。其突出之处在于 Token Vault：智能体针对外部身份提供商（Google、Slack、GitHub、Box 或自定义 OIDC 连接）对用户进行一次身份认证后，Auth0 负责获取并静默刷新 token，让智能体能够代表用户调用这些提供商的 API，而你的代码无需直接接触 refresh token。对于需要人类在智能体继续操作前明确批准的操作——付款、删除、不可逆的发送——Auth0 支持 Client-Initiated Backchannel Authentication（CIBA）和 Rich Authorization Requests（RAR），它们将一个特定的、人类可读的批准请求带外推送到用户的设备上，独立于智能体自己的请求流程。Auth0 FGA 还在 RAG 流水线内部强制执行文档级和关系级访问控制，这是一个与工具授权不同的问题，但使用智能体密集型团队经常遇到。

Stytch Connected Apps 现归 Twilio 管辖（2025 年 11 月收购完成），它采取了"附加而非迁移"的姿态，明确针对拥有现有（可能是遗留）身份技术栈的团队。它实现了带 PKCE 的 OAuth 2.1、动态客户端注册，以及一个即插即用的同意屏幕，它最清晰的不同之处在于 Cloudflare 的深度集成。Cloudflare 的 Agents SDK 附带一个 McpAgent 类，自动处理 MCP 传输和认证，背后由一个实现完整 OAuth 服务器流程的 workers-oauth-provider 库支持 Workers 部署——Stytch 的 Trusted Auth Tokens 与该路径无缝集成，使其成为这三个选项中对于实际在 Workers 上部署远程 MCP 服务器的团队而言边缘原生程度最高的方案。

Composio 不是身份提供商，也不应该被评估为其他三个的简单替代品，尽管它经常出现在相同的比较搜索中。它是一个智能体集成平台——跨大量预构建 SaaS 连接器目录的托管 OAuth、工具 schema 定义、执行控制、重试逻辑和速率限制处理——其中认证是更广泛技术栈的一个组成部分，而非产品本身。如果你的问题是"我需要我的智能体在我的企业 IdP 内部安全地行动"，Composio 并不在解决那个问题。如果你的问题是"我需要我的智能体针对 60 个不同的 SaaS API 进行认证，而无需手工编写 60 个 OAuth 集成"，那它解决的是一个真实存在的、不同的问题，这是 WorkOS、Auth0 和 Stytch 都没有触及的领域。

每个选项实际是如何构建的

架构差异比功能列表差异更重要，因为它们决定了在高负载下什么会出问题，以及后续什么无法在不迁移的情况下改变。

WorkOS AuthKit 被构建为一个附加的授权层：它不想拥有你的用户表。在底层，AuthKit 充当 MCP 所需的 OAuth 2.1 授权服务器，但它将"这个人是谁"这个实际问题向外委托——通过标准 SAML/OIDC 联盟委托给 Okta、Entra ID、Google Workspace 或你的企业客户已经运行的任何 SSO——然后在这个联盟身份之上签发 MCP 作用域的 token。FGA 被实现为一个独立的关系型授权引擎（概念上类似于 Google's Zanzibar 模型），这就是为什么它能将"这个智能体可以代表这个特定用户读取这个特定日历"表达为一个一等关系，而非一个扁平的 scope 字符串。代价是 FGA 是一个需要建模和运维的第二系统，而不是 OAuth 流程中的一个复选框。

Auth0 的架构走向另一个方向：集中化而非联邦化。Token Vault 位于 Auth0 自有基础设施内部，持有第三方令牌（Google、Slack、GitHub、Box），代表 AI 智能体进行交换，因此你的应用代码永远不会直接看到或存储长期有效的第三方凭证——Auth0 在内部负责刷新和轮换。CIBA 和 RAR 建立在 Auth0 已有的后通道模式之上，用于渐进式 MFA，现已被改造用于 AI 智能体授权：授权请求与人工审批通过与 AI 智能体自身 API 调用不同的独立通道传输，这正是让 AI 智能体轮询"人工是否已批准"而不必像基于浏览器的 OAuth 那样阻塞在重定向上的原因。这种后通道优先的设计正是使 Auth0 成为异步、非交互式 AI 智能体工作流最有力选择的原因——AI 智能体无需打开浏览器标签页即可获得人工签署。

Stytch 的架构是三者中边缘导向最明确的。Trusted Auth Token 被设计为在边缘本地验证——例如在 Cloudflare Worker 内部——无需每次请求都往返 Stytch 集中式服务器，而是使用针对已发布签名密钥的标准 JWT 验证。这正是 Cloudflare Workers 集成不仅仅是合作伙伴公告的原因：Stytch 的令牌模型专为高请求量、低延迟的廉价验证而构建，而这恰恰是在边缘运行并处理多个并发 AI 智能体会话工具调用的 MCP 服务器所需要的配置文件。WorkOS 和 Auth0 更集中的模型并非边缘部署的阻碍，但它们并未像 Stytch 那样针对这种请求模式进行优化。

自去年以来具体发生了什么变化

直到 2025 年大部分时间里，"MCP 认证"不过是一堆静态 API 密钥、临时 bearer 令牌，以及各实现自行其是的 OAuth 流程——对原型可行，在生产规模下是隐患，且无人审计。三件事的汇合终结了这一局面：

第一，规范本身得到了加固。无状态核心重写（移除了 initialize 握手和 Mcp-Session-Id 头）是开发者注意到的头条变更，但具有持久影响的授权收紧：MCP 服务器现在按要求是 OAuth 2.1 资源服务器，而非约定俗成。

第二，厂商将专用产品线正式化，而非将 AI 智能体认证作为功能子弹点。Auth0 于 2026 年 5 月正式 GA，Okta 自己的 MCP 服务器（一个让 AI 智能体通过自然语言管理 Okta 本身的协议层，每个工具调用都强制执行最小权限）在五个月内相继推出。WorkOS 专门为工具级 AI 智能体作用域构建了 FGA。Stytch 明确将 Connected Apps 围绕 MCP 重新定位，而非作为通用 OAuth 即服务产品。

第三，标准讨论超越了 OAuth 最初的人坐在浏览器前的模型。微软的 Entra Agent ID 于 2026 年 4 月达到正式可用，将 AI 智能体身份视为专门的服务主体，持有自己短期、由蓝图颁发的令牌——与用户身份和传统服务账户均不同。NIST 于 2026 年初发布了 AI 智能体身份概念论文。IETF 正在努力在 SCIM 中标准化 /agents 资源，以便 AI 智能体身份可以通过组织已用于人类的同一目录同步机制进行配置和取消配置。这些都尚未完成。所有这些都表明，当前的 WorkOS/Auth0/Stytch 这代产品是一个仍在被定义的类别的第一版。

为什么这应该特别引起你的关注

成本。WorkOS 和 Auth0 都将重要功能——尤其是 FGA——放在定制企业定价之后，而非透明的自助服务层级，Auth0 的 FGA 是核心平台之上的明确附加成本，再加上 Okta 2021 年收购 Auth0 留下的定价复杂性（真实的产品重叠，而非仅仅是营销噪音）。Stytch 是三者中更基于用量、更友好自助服务的，尽管它现在运行在 Twilio 的计费和路线图轨道之下。

延迟和运维。Stytch 的 Workers 原生路径为边缘部署的 MCP 服务器避免往返集中式认证服务器，而 WorkOS 和 Auth0——围绕更传统的集中式授权服务器构建——原生并不提供这种能力。如果你的 MCP 服务器运行在 Cloudflare 边缘，那就是真正的架构契合，而非偏好。

开发者体验。Auth0 开箱即用集成了 LangChain、LlamaIndex 和 Vercel AI SDK，如果你已在该生态系统中，可以缩短从框架代码到可工作授权流程的路径。WorkOS 优化的是相反的情况：最小化对组织现有身份提供商的干扰，因此你将 AuthKit 与 Okta 或 Entra ID 集成，而非替换其中任何一个。Stytch 的嵌入式同意 UI 移除了一块大多数团队在手工构建第三个"允许此 AI 智能体访问你的日历？"页面之前都会低估的自定义前端工作。

锁定问题。这是最容易产生营销误导的地方。Stytch 和 WorkOS 都明确宣传"无需迁移"——你保留现有的用户数据库和身份提供商，他们的产品只是与之并存。对于绿地团队，在 AI 智能体上采用 Auth0 意味着同时采用 Auth0 整个平台的引力，这是被包装成功能的更重承诺。

安全深度。这是三家厂商首页都不会前置的部分，值得单独一节。

各方案的实用场景

WorkOS AuthKit 适合向企业客户（每个客户运行自己的 IdP）发布 MCP 服务器的 B2B 平台团队。具体来说：一个数据分析 SaaS 添加了一个 AI 智能体，客户可以将其指向自己的数据仓库，每个客户的安全团队需要在自己的 SSO/SCIM 管理环境中看到哪些用户授权了该 AI 智能体、它调用了哪些工具，并通过与他们已用于其他所有应用相同的 admin console 撤销该访问权限。AuthKit 的 Admin Portal 正是为这种自助式 IT 管理员工作流而构建的，FGA 让平台团队能够将 AI 智能体限定到特定的数据仓库表，而非整个账户。

Auth0 for AI Agents 适合在用户现有 SaaS 账户中跨账户行事、具有低风险和高风险操作混合的 AI 助手——起草日历邀请与发送电汇确认。低风险、无需人工的操作（读取日历、检查收件箱）由 Token Vault 在后台静默处理；高风险操作通过 CIBA/RAR 在 AI 智能体继续之前向用户手机推送明确的、人工可读的审批请求。这是目前正在推出的大多数面向消费者和内部"行政助理"AI 智能体的形态。

Stytch Connected Apps 适合一家初创公司，构建一个远程 MCP 服务器，旨在同时被许多不同的 AI 客户端（Claude、ChatGPT、自定义 AI 智能体框架）调用，出于成本和延迟原因部署在 Cloudflare Workers 上，且不想首先建立或迁移到完整的 CIAM 平台。Cloudflare Agents SDK 的 McpAgent 类加上 Stytch 的 Trusted Auth Token 是目前从零到符合规范的 OAuth 2.1 MCP 服务器的最简可行路径。

Composio 作为异类，适合构建需要长时间尾 SaaS 工具（Notion、Linear、HubSpot、Slack、GitHub 等十多个）认证写访问的内部自动化 AI 智能体的团队，其工程成本不在于任何一个工具的治理深度，而在于需要手工构建和维护的 OAuth 集成数量——随着每个提供商 API 的演进而持续投入。

他们都没有明确宣传的缺口

WorkOS 自己的 AI 智能体认证开发者指南——一篇供应商博客中真正坦诚的文章——直白地指出"委托链在规模上会崩溃"，并将跨 AI 智能体权限提升、多 AI 智能体管道中的会话走私以及通过共享服务账户进行的被迷惑副主管攻击列为开放问题，而非已解决的问题。这家销售 AI 智能体认证产品的公司做出了一个引人注目的承认，它与独立身份供应商的分析一致：发放给人类的标准 OAuth 令牌携带广泛上下文——角色、部门、该人可访问的完整应用集——这在人类使用时没问题，在 AI 智能体完全继承时就危险了。身份领域的多个来源将修复描述为令牌交换：将那个广泛的人类令牌交换为一个狭窄的、短期有效的、精确限定于 AI 智能体正在执行任务的令牌，加上可审计的 On-Behalf-Of 链，将每个下游操作链接回授权它的人类（或 AI 智能体）。

None of WorkOS、Auth0 或 Stytch 目前将上述能力作为完整的、开箱即用的方案出售。Auth0 的 Token Vault 和 CIBA/RAR 流程在特定场景下（智能体代表用户调用第三方 API，并在敏感操作前设置人工审批门槛）已经做到了部分实现——这是真实且已上线的功能。但这些厂商都没有完全解决的问题，是一个更难、仍在发展中的挑战：当一个编排智能体将一个缩窄范围的凭证传递给子智能体，子智能体再将一个进一步收窄的凭证传递给工具调用，且在链条中途条件变化时持续进行策略重评估（这就是 Shared Signals Framework 中称为 CAEP——Continuous Access Evaluation Profile 的概念）。Entra Agent ID 和少数专业身份供应商正在 2026 年积极构建这一层，有理由相信无论今天选择哪个供应商，在 12 到 18 个月内你都会重新审视这个决策。

另一个值得指出的疏漏：Stytch 被 Twilio 收购后的发展轨迹是一个真实的可维护性问题，而非 FUD（恐惧、不确定、怀疑）——即便是与供应商无关的行业报道也直接指出了这一点。Auth0 的 FGA 作为附加组件的定价模式，以及 Auth0/Okta 产品重叠带来的整体复杂性，同样是一个未被充分宣传的成本中心。WorkOS 对自助服务层级以上任何方案的"定制化定价"，意味着你只有在深度卷入销售对话、切换供应商已经感到成本高昂时，才能知道真实的成本。

7 月 28 日的规范更新做了真实、有用的工作：它将 MCP 授权从"每个实现都自行发明"推进到规范强制执行的 OAuth 2.1 基线，并带有标准化发现机制和受众绑定。这是一个真正的整合，也是为什么三家供应商都能合理地声称 MCP 兼容性，而无需附加专有方案的原因。但"MCP 合规的 OAuth"解决的是登录和授权问题——证明一个智能体是其声称的身份，并获得用户的明确许可——这个问题现在已经被成熟供应商以多种方式真正解决了。

它没有解决的是委托深度问题：当一个智能体到智能体链条中深入三层时，最初作为窄化、人工批准的授权开始的令牌需要再次、再次缩窄，并且需要一条能经受安全审查的审计追踪。这不是对任何一家供应商的批评——而是对标准（Entra Agent ID、SCIM 提议的 /agents 资源、CAEP）现状的诚实评估：基础原语已进入普遍可用，组合应用仍处于早期阶段。为解决你今天面临的登录和授权问题而购买，但要在预算中假设其上的委托层将是第二次采购，而不是这三个厂商已经勾选的对勾。

如果你的组织已经运行 Okta 或 Entra ID，且你的智能体需要代表用户调用第三方 SaaS API，并在敏感操作前设置审批门槛——比如一个能起草邮件但需要人工确认后才能发送的 AI 助手——Auth0 for AI Agents 已经构建了最完整的解决方案，代价是加深你对 Okta 技术栈的依赖。

如果你需要企业 SSO、SCIM 和工具级授权，并叠加到你已经运行的身份提供商上，且不迁移用户基数、不采用完整的 IAM 平台，WorkOS AuthKit 是更精准的选择——前提是你对在超过自助服务层级后谈判价格没有顾虑。

如果你在 Cloudflare Workers 上发布远程 MCP 服务器，想要 OAuth 2.1、DCR 和一个可用的同意屏幕，且自己不需要拥有 CIAM 基础设施，Stytch Connected Apps 在架构上是最接近的匹配——但需要留意 Twilio 未来一年的产品方向。

如果你的实际瓶颈是广度——一个智能体需要认证访问数十个 SaaS 工具，而不是对一个企业身份图谱进行深度治理——这三家都不合适，Composio（或类似的集成平台方案）值得评估，而不是强行适配。

如果你的系统涉及智能体向超过一跳的子智能体链条中委托，请将这三家都视为必要但不充分的。这个堆栈层仍在由这些供应商和专用身份基础设施供应商构建，今天选择登录提供商并不能弥合那个差距——它只是第一次清晰地告诉你，差距究竟从哪里开始。

讨论问题：对于已经在运行生产级多智能体系统的团队——一个智能体的输出触发另一个智能体的工具调用——你们目前是如何实际划分和审计智能体之间凭证交接的？你们是依赖 OAuth 提供商的原生委托支持，构建自定义令牌交换层，还是暂时接受混乱代理风险？