四家身份厂商都会卖给你"面向 AI 智能体的认证"，而他们说的是两件互不兼容的事。一件是让别人的智能体带着一枚受限且可撤销的令牌进到你的应用里；另一件是让你的智能体带着属于你用户的凭据出去访问 Gmail 或 Salesforce。多数智能体产品两件都需要，而没有哪个厂商页面会告诉你它做的是哪一半；这个选择还几乎不可逆，因为它会落进你的数据模型。先按方向选，再看你能不能整体采用一个平台——并且要诚实地承认：一个存着用户完整授权的保险库，只是把凭据挪了个地方，并没有把它变小。
速览
四个平台，按各自主打的方向而非功能数量排列。
| 平台 | 主打 | 形态 | 最合适的场景 |
|---|---|---|---|
| Auth0 for AI Agents | 出站——Token Vault，外加基于 CIBA 与 PAR 的异步审批 | 一个完整的 CIAM 平台，智能体能力叠在上面；自 2025 年 11 月起正式可用 | 已经在用 Auth0、或愿意采用它，且要造一个代用户操作第三方账号的智能体 |
| Descope | 两个方向都做——Inbound Apps 与 Outbound Apps 是两个独立的具名产品 | 可视化流程编排；50 多个出站集成模板；令牌取用由一层访问控制面把关 | 两个方向都需要、且希望在同一套心智模型下从一家厂商拿到的产品 |
| Stytch Connected Apps | 入站——把你的应用变成一个 OAuth 2.1 提供方 | PKCE、动态客户端注册、开箱即用的同意界面；可作为独立层架在既有 CIAM 之上。Twilio 于 2025 年 11 月完成收购 | 已有一批不打算迁移的用户，而下个月就得对外提供一个 MCP 服务器 |
| WorkOS AuthKit / Connect | 入站——符合 MCP 的授权服务器，自 2026 年 5 月起正式可用 | AuthKit 改一个配置值就变成 MCP OAuth 2.1 服务器；Connect 作为中间件架在你既有的身份系统前面 | 企业 SSO 早已搞定的 B2B SaaS，想在不动登录框的前提下加上智能体访问 |
两个方向，以及把它们混作一谈的代价
入站是你的应用变成一个 OAuth 授权服务器。别人的智能体——一个聊天客户端、一个 MCP 宿主、一个合作方的自动化——想要够到你用户的数据。难点在于：这个客户端没有浏览器会话、可能三十秒前才刚刚动态注册过自己，而且需要一枚窄到"就算泄漏你也能接受"的令牌。MCP 是让所有人同时对这件事变得紧迫的原因，也是这四家在这里都很强的原因。
出站是你的智能体需要一枚属于你用户的、指向一个你并不拥有的服务的凭据。难点在于存储、在过期前刷新、在任务中途追加一个作用域而不必重启对话，以及决定你自己的哪些组件才有资格取出令牌。这是一个保险库问题，它和前一个长得毫不相像。
混作一谈之所以昂贵，是因为这两件事落在你系统里的不同位置。入站是你 API 表面的属性；它可以晚点再加，而 Stytch 与 WorkOS 存在的意义恰恰是让你在不碰既有身份提供方的前提下晚点再加。出站是你数据模型的属性——哪个用户、哪条连接、哪些作用域、哪次智能体运行、哪条取用策略——事后补上它，意味着重写你的智能体里每一件工具获取凭据的方式。
翻开任何定价页之前，先做这个实用检验：为你的产品写下这句话——"智能体需要一枚令牌来……"。如果这句话以"……够到我们的数据"结尾，你面对的是入站问题；如果以"……够到用户的 Google 账号"结尾，你面对的是出站问题。如果两句都写了，你要么需要一家把两半都点名的厂商，要么需要两家厂商，加上一条清晰的分界。
各自真正强在哪里
Auth0：出站这条线最完整，代价是它连着一个平台
Token Vault 保管指向第三方工具的 OAuth 凭据，并处理那套刷新与交换的机器——否则你会把它写两遍，并且有一遍会写错。真正显眼的是 Async Authorization：借助 CIBA 与 PAR，智能体可以在任务中途暂停、带外请求人工批准、然后继续——这正是长时运行的智能体所需要的机制，也是多数团队最后自己用一张数据库表加一个轮询循环手搓出来的那个东西。自 2025 年 11 月起正式可用，免费额度含两个 Token Vault 连接应用，这个量足够拿来真造点东西，而不只是演示。
代价在于这份承诺的形状。Auth0 是一个完整的客户身份平台，而最顺手地采用它的智能体能力，通常意味着采用这个平台。如果你本来就在上面，这是笔划算的交换；如果你的用户住在别处，它就很贵。
Descope：唯一把两半都做成具名产品的一家
Inbound Apps 把你的 API 变成面向智能体的 OAuth 服务器并支持自定义作用域；Outbound Apps 则是一个令牌保险库，带五十多个集成模板——Gmail、HubSpot、GitHub、Snowflake、Slack、Notion、Shopify——而更有意思的是，它还有一层访问控制面，专门管"哪些智能体与用户才有资格为某条连接取出令牌"。在这几家的页面里，这是唯一一个瞄准了真实智能体威胁模型、而不是瞄准 OAuth 规范的细节：它假定你自己系统内部存在一个被攻陷或被绕晕的组件。
如果你在造的产品是"用户接入自己的工具、你的智能体随后代为操作"，这是最贴合的一家；理由在于你在两个方向上拿到的是同一套心智模型，而不是两个对"连接"是什么各执一词的集成。
Stytch：架在一个你不打算替换的身份系统之上的独立入站层
Connected Apps 把你的应用变成一个 OAuth 2.0/OIDC 提供方——OAuth 2.1 加 PKCE、动态客户端注册、开箱即用的同意界面，以及授权的全生命周期管理。决定性的性质在于：它可以作为一层架在既有 CIAM 之上运行，而不必迁移你的用户库，这就把"我们得对外提供一个 MCP 服务器"从一个季度的身份工程压缩成一次集成。Twilio 于 2025 年 11 月完成了对 Stytch 的收购，这一点值得知道，但理由是路线图而非技术。
WorkOS：成为 MCP 授权服务器的最小侵入路径
AuthKit 改一个配置值就变成符合 MCP 的 OAuth 2.1 授权服务器；而 Connect 是那条独立路径——架在你既有身份系统前面的中间件，只处理 MCP 的那些 OAuth 流程：发现端点、动态客户端注册、PKCE、令牌签发、同意。Auth for MCP 于 2026 年 5 月正式可用，包含客户端 ID 元数据注册与代表用户的令牌交换。如果你的企业 SSO 与 SCIM 早已搞定、只是需要让智能体能完成认证，这就是改动最小的那个 diff。
没人拿来做卖点的那个维度：这枚令牌到底有多小？
下面这件事值得从这几款产品里带走。身份层是那唯一一项在提示词注入已经得手之后仍然管用的智能体控制，因为它在模型之外被强制执行——一个被说服去做不该做之事的智能体，依然做不了它的令牌不允许的事。这正是这个品类对智能体的重要性远高于它当年对应用的重要性的全部原因。
但它的兑付程度，与令牌有多窄成正比，而各家的默认都是"作用域等同于用户授予的那一份"。你的智能体只要求起草一封回信；它手上却握着一枚能读整个邮箱、并以用户身份发信的凭据，因为 OAuth 同意页给的就是这个，保险库存下的也就是这个。保险库把凭据挪出了你的进程——这确实有价值，也不是没意义——但一次注入得手之后的爆炸半径纹丝未动。
由此推出三件事，而它们没有一件在定价页上。
向提供方索要它能给的最窄作用域，然后在你自己的中间件里再收窄一次。各提供方在作用域粒度上差别极大，而你继承的是他们的天花板。天花板太高的地方，唯一剩下的控制就是你自己的一层代理，在厂商令牌之上强制执行按任务的限制——这与智能体的出站控制在网络层给出的是同一个论点。
把"取用"当作一次授权决策，而不是一次查表。哪个智能体、代表谁、为了哪个任务，才能把这枚令牌从保险库里取出来？Descope 的访问控制面把这件事显式化了；凡是没有显式化的地方，默认就是"任何持有 SDK 的代码都行"。
在你需要撤销之前先演练撤销。撤销是这一层给你的最强的东西，也是最少被真正演练过的。你能在不让用户登出的前提下掐掉某一个智能体的访问权吗？能在不影响其他连接的前提下掐掉某一条连接吗？两个问题里只要有一个是"不能"，那你手上这个急停开关的分辨率就比你以为的低——它到底该拦下什么，见急停开关。
什么情况下选哪个
| 情形 | 选 | 理由 |
|---|---|---|
| 要对外提供 MCP 服务器，既有身份提供方不动 | WorkOS Connect 或 Stytch Connected Apps | 两者都是为"架在现任者前面、不迁移用户"而设计的 |
| 智能体要操作用户的 Gmail、Slack 或 Salesforce | Auth0 Token Vault 或 Descope Outbound Apps | 存储、刷新与增量作用域请求才是真正的工作量，而两家都交付了 |
| 长时运行、必须暂停等人工批准的智能体 | Auth0 | CIBA 与 PAR 是一等能力，而不是你自己拼出来的东西 |
| 两个方向、一家厂商、对"连接"只有一套定义 | Descope | Inbound 与 Outbound Apps 是同一平台下的两个独立产品 |
| 需求已被企业 SSO 与 SCIM 主导的 B2B SaaS | WorkOS | 智能体访问变成一次配置变更，而不是一个项目 |
对四家都适用的一条提醒：这个品类跑得够快，以至于上面那张矩阵中间两行，在你读到关于它们的采购材料时多半已经变了。方向上的划分是耐用的；功能清单不是。请对着当前文档去核实出站与异步审批那两行，并据此给任何对比文章——包括这一篇——打上相应的折扣。
常见问题
入站与出站智能体授权有什么区别？
入站是指你的应用充当 OAuth 授权服务器，让外部智能体或 MCP 客户端能取得一枚受限且可撤销的令牌来够到你用户的数据。出站是指你自己的智能体取得一枚属于你用户的凭据，用来调用 Gmail 或 Salesforce 这类第三方 API。它们是方向相反的两条流，难点也不同——一边是同意与动态客户端注册，另一边是令牌存储与刷新——而多数智能体产品两者都需要。
这几个平台里哪些做出站令牌？
Auth0 for AI Agents 提供 Token Vault；Descope 提供 Outbound Apps，带五十多个集成模板，并有一层访问控制面管辖哪些组件可以取出令牌。Stytch Connected Apps 与 WorkOS 主打的都是入站那一半——成为面向智能体的 OAuth 授权服务器——而不是保险库。
CIBA 是什么，智能体为什么需要它？
客户端发起的反向通道认证（CIBA）让应用可以带外请求用户批准，不需要浏览器跳转。对长时运行的智能体来说，这正是让任务能够暂停等人工同意、然后继续的机制，而不是因为需要令牌的那一刻恰好没人在场就失败掉。Auth0 把它作为一等的异步授权能力对外提供。
能不能在不替换身份提供方的前提下加上智能体认证？
入站那一半可以。WorkOS Connect 作为中间件架在既有身份系统前面，只处理 MCP 的 OAuth 流程；Stytch Connected Apps 则能作为独立层架在既有 CIAM 之上运行，不必迁移用户库。出站那一半更难外挂，因为它落在你的数据模型里，而不是落在 API 边缘。
令牌保险库能降低提示词注入的风险吗？
部分能。它把凭据挪出了智能体进程，这有真实价值；但它存下的那枚令牌，作用域通常等同于用户在同意页上授予的那一份——往往是对整个账号的读写。注入得手之后，可触达的面等于令牌的作用域而不是任务的作用域，所以保险库是把凭据挪了个地方，而不是把它变小了。真正缩小爆炸半径的，是按任务收窄作用域，以及把"从保险库取用"当成一次独立的授权决策。
在敲定之前该测什么？
测撤销，并且要测到你真正需要的那个分辨率。试着在不让用户登出的前提下掐掉某一个智能体的访问权，以及在不影响其他连接的前提下掐掉某一条第三方连接。另外测一次任务运行中途的增量作用域请求，因为这条流最常被发现需要重启用户会话。
延伸阅读
本站相关：
- 智能体身份与权限——认证、授权与归属为何是三个问题。
- 为智能体收窄凭据——把令牌收窄到任务。
- MCP 认证与 OAuth 2.1——这些入站产品所实现的协议。
- 智能体身份——运维一侧，包括撤销。
- A2A v1——当调用方是另一个智能体而不是客户端时，会有什么不同。
- 提示词注入——这一层依然扛得住的那种攻击。
项目来源：
- Auth0 for AI Agents is now generally available — Auth0
- Outbound Apps: Connect AI Agents With External Tools — Descope
- Connected Apps: auth for AI agents and MCP that fits your existing identity stack — Stytch
- Model Context Protocol — WorkOS AuthKit docs
- Best Authentication Platforms for AI Agents and MCP Servers in 2026 — MarkTechPost