在代理应用中的身份认证变化与不变之处

最近我审阅了这篇文章，其中提到了代理身份认证：

我们开始看到这种情况的迹象。例如，最新的 MCP 规范包括一个基于 OAuth 2.1 的授权框架，这表明有可能转向给予 AI 代理具有范围和可撤销的令牌而不是原始密钥。我们可以想象一个场景，在这个场景中，一个 AI 代理并没有获得你的实际 AWS 密钥，而是获得了一个短期的凭证或权限令牌，可以让它执行一个定义狭窄的操作。

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

许多朋友和不在安全或 CIAM 领域的人认为这是一个新事物，但实际上并不是。OAuth 是一个标准的基于令牌的授权协议，涉及具有范围权限（访问令牌）的令牌。这些令牌是时间敏感和范围限制的，确保了资源和服务的安全和正确的访问控制。在全球 SaaS 市场（AI 之前），大多数专业身份解决方案已经基于此构建。

当你将谷歌账户连接到像 Notion 或 Zoom 这样的第三方应用时，它使用 OAuth 只请求必要的权限，如访问你的日历或联系人，而不会暴露你的谷歌密码。你可以随时从谷歌账户设置中撤销此访问。这种委托访问模式正是 OAuth 设计的目的，也是当前扩展到代理应用的基础。

代理世界中没有改变的是什么#

身份认证不是新事物，仍然基于 OAuth 2.1#

有两个主要的协议出现：MCP 和 A2A。

• MCP 聚焦于大语言模型（LLM）与应用工具和上下文的交互。
• A2A 聚焦于启用代理间任务交换。

但在身份认证和授权方面，二者仍依赖于业界成熟的标准，如 OAuth。

MCP 授权服务器 必须 实现 OAuth 2.1，并为机密和公共客户端采取适当的安全措施。

A2A 客户端负责通过 A2A 协议外部的流程获取所需的凭证材料（例如，OAuth 2.0 令牌、API 密钥、JWT）。这可能涉及 OAuth 流程（授权码、客户端凭证），安全密钥分发等。

正如谷歌所说：

A2A 旨在无缝集成现有企业基础设施和广泛采用的最佳实践，而不是发明新的、专有的安全和运营标准。

代理需要独特的身份吗？#

大量的炒作和 FOMO 内容强调了这样一种想法，即随着代理的普及，我们需要一个管理代理身份的系统。

答案是：是，也不是。

是，因为我们正在在人机之间引入新层次。确有实际需要：

• 管理和识别代理
• 分配唯一 ID
• 跟踪日志
• 审核操作（了解是否由人类或代理执行任务）

然而，在多数技术案例中，没有必要创建“代理身份”这种正式概念。

代理 ≠ 用户，≠ 服务账户。

在每个代理背后，总有用户，用户身份通常就足够了。

如今，多数代理：

• 根据用户授权行事（例如，OAuth 令牌）
• 执行逻辑或进行 API 调用
• 执行短期的，临时任务（无需追踪）

在这个意义上，代理只是一个工具即功能，不需要全球唯一 ID。

例如：

• 调用你的日历 API 的 GPT 代理只需要你授予的访问权限。
• LangChain 代理只要能够调用正确的工具就可以工作，它不需要身份。

甚至在 AI 之前，我们就有了机器对机器 (M2M) 验证的概念。

M2M 指的是服务间的自动化数据交换，过程中无需人为干预。

在这种情况下，身份验证通常使用客户端应用或服务账号。

如果你真的希望你的代理有一个身份（用于审计等），你可以使用应用 ID，这样就足够了。

你仍然需要定义产品的架构#

这没有改变。无论你的产品是否涉及代理，你的身份认证系统的架构都取决于你的用户是谁以及你的系统如何与他们互动。

如果你是在开发面向消费者的代理产品： 你将需要轻量级的登录方式（电子邮件，电话，社交登录），以及一个统一的用户池来管理与应用及其代理进行互动的个人用户。代理使用委托令牌（例如，通过 OAuth）代表这些用户行动。

例如：

假设你正在创建一个 AI 日程助手，或一个 AI 驱动的日历机器人。

每个用户使用他们个人的谷歌账户登录。系统使用 OAuth 获得访问日历的权限。代理没有自己的身份，它使用用户的令牌来安排会议，检查可用性或发送提醒。身份架构很简单：一个全球用户池，令牌存储，以及每个用户的同意跟踪。

如果你是在开发一个 B2B 代理平台：

你将需要在组织层面上支持身份认证，而不仅仅是个人用户。这包括：

1. 为企业客户提供单点登录 (SSO)
2. 工作区或租户级别隔离
3. 组织级别的代理委派策略（例如，控制代理在团队之间能做什么）
4. 员工代理活动的管理员级别可见性和日志跟踪

例如：

假设你正在构建一个平台，提供 AI 代理以自动化内部工作流 —— 像是监控日志并发送警报的安全分析机器人，或从 CRM 数据中草拟电子邮件的销售助手。

使用你平台的每个公司希望：

1. 使用他们现有的 SSO 登录
2. 控制代理能访问什么（例如，内部工具、文档系统）
3. 查看哪个代理执行了什么任务，在哪个员工的授权下

在这种情况下，你的身份架构需要支持多租户设计，范围代理权限和特定业务租户的策略。代理虽代表用户行动，但权限和身份边界由企业租户强制执行。

在这两种情况下，身份模型定义了代理如何操作，它们可以访问什么，以及你的系统如何确保责任制。

使用此指南帮助你规划身份和产品架构。

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

你仍需要安全层来保护你的代理驱动应用#

无论是否是代理应用，这些基础安全层都是保护用户和系统所必需的：

• 多因素认证 (MFA)

  即便凭证泄露也能防止未经授权的访问。

  示例：如果一个代理帮助你执行高风险操作，例如进行交易或更改身份设置，它应该让人为控制在其中，并使用 MFA 在继续之前确认操作。

• CAPTCHA

  阻止自动化滥用，如凭证填充或机器人驱动的注册。

  示例：在 3 次登录失败后显示 CAPTCHA，以防止暴力破解攻击。

• 基于角色的访问控制 (RBAC)

  确保用户和代理只能访问他们被允许的内容。

  示例：一个公司工作区的 AI 助手可以读取日历事件，但不能访问账单数据，除非被明确分配了更高权限。

• 无密码登录

  改善用户体验并降低弱密码风险。

  示例：让用户使用发送到邮箱的魔法链接或诸如 Face ID 的生物识别提示登录。

这些功能适用于传统和基于代理的应用，尤其是在代理开始跨敏感数据和系统操作时。

代理世界中改变了的是什么#

身份认证比以往更为重要#

随着代理和多代理工作流的出现，我们看到了新的用户、代理、API 和 MCP 服务器相互作用的用例。这些场景的数量和种类正在迅速增长，比以前多得多。

只要这些连接发生，授权就比以往更为重要。用户必须给予明确的同意，权限需要在跨系统中谨慎管理。这就是为什么大家都在谈论确保有一个**“人在回路中”**，确保用户对代理能做什么以及获得授权的范围有足够的控制和可见性。

你的 AI 应用可能需要集成许多外部服务#

MCP 生态系统正在扩展，这意味着你的应用不仅仅是一个独立的服务：它是一个更大、互联网络的一部分。

为了向 LLMs 提供丰富且有用的上下文，代理可能需要：

• 访问多个 MCP 服务器

  示例：想象一下，一个 AI 项目经理从 Jira 获取任务更新，从谷歌日历获取团队可用性，从 Salesforce 获取销售数据，而这些可能由不同的 MCP 服务器驱动。为了生成一个每周总结，代理必须安全地与多个数据源互动。这时，身份认证和授权的作用在于保护每条连接，控制数据共享方式。

• 连接外部 API 和工具

  示例：一个客户支持代理可能需要从 Shopify 检索订单历史，在 Zendesk 中更新工单，并在 Slack 中触发工作流。没有集成，代理将被孤立且无效。

随着代理承担的责任越来越多，集成变成了关键。你的 AI 产品不仅与自身能力相关，还涉及它在一个互联生态系统中访问什么、协调什么和推理什么。这就是为什么以安全灵活的方式构建互操作性比以往任何时候都更为重要。

你需要接受开放标准：OAuth/OIDC 比以往更为重要#

在 AI 时代，对安全、灵活集成的需求正在增长。这使得 OAuth 2.0 和 OIDC 比以往更为重要。

关键用例包括：

• 远程 MCP 服务器：让第三方代理使用委托的令牌安全访问你的产品。
• 第三方集成：允许其他工具或代理连接到你的应用（例如，项目管理平台），而不需要原始凭证。
• 代理开发：构建能够安全跨服务代表用户行事的 AI 代理。
• 智能设备：使用 OAuth/OIDC 进行操作，如让 AI 驱动的记录器验证用户并连接到云端 —— 特别是在用户界面有限的情况下。

这些协议提供了安全、基于令牌、用户同意的访问权限。

这在代理化、互联的系统世界中至关重要。请查看这篇文章以了解为什么 OAuth 和 OIDC 很重要

在代理软件时代设计的信任和规模#

随着代理产品的发展，身份和授权的核心原则仍然相同，但背景在变化。代理引入了新的委托、同意和访问层面。这就是为什么坚持开放标准如 OAuth、建立清晰架构和执行坚实安全实践不只是最佳实践，而是基础。在现在设计时仔细思考意味着你的系统将以信心、灵活性和信任扩展到一个 AI 驱动的未来。