OAuth 2.0 的隐含假设正在被 AI Agent 打破

OAuth 的设计对象是人类。AI Agent 改变了一切。

我直说了。OAuth 2.0 虽好，但它从来没有被设计成让"用户"是一个每分钟做出五十个决策、无人值守运行的软件 Agent。我们一直在让规范迁就 Agent，实际上规范假设的是一个坐在浏览器前、点击"授权"按钮的人类。这个假设现在正在被打破，而且大多数正在构建 AI Agent 的团队还没有完全意识到问题有多大。

让我解释一下我的意思。

OAuth 协议中的人类假设

经典的 OAuth 2.0 授权码流程大致是这样的：用户点击登录，被重定向到身份提供者，看到一个consent 页面，点击"授权"，然后带着授权码返回，应用用这个授权码换取 token。这个流程中的每一步都假设有人类在场，看着屏幕做出判断。

现在把一个 AI Agent 放入这个循环中。Agent 端没有浏览器会话在等待。没有人类的眼球在阅读"此应用想要访问您的日历和邮件"。Agent 不会点击"授权"；它在调用 API，而且它需要在凌晨 2 点无人值守的情况下做这件事，有时在几秒钟内链式调用五六个不同的服务。

三腿 OAuth 舞蹈只为一件事件构建：人类在特定访问授权的时刻，当场给出知情同意。Agent 至少在三个方面打破了这个假设。

实际破防的地方

1. 请求时没有人类在场同意。同意必须在事前捕获，或预先委托，因为 Agent 无法在任务中途停下来等待某人点击按钮。这将同意从交互式的、请求时发生的行为，变成了必须预先定义的策略。

2. 身份是分层的，不是单一化的。在经典 OAuth 中，token 代表"此用户授权此应用访问此范围"。有了 Agent，你实际上有三重身份堆叠在一起：发起任务的人类、执行任务的 Agent，有时还有第一个 Agent 派生出来完成较小工作的子 Agent。标准 OAuth token 不是为携带这种链条而构建的。

3. Session 生命周期假设不再成立。人类 Session 可能持续一个小时，最多一天，有自然的边界比如合上笔记本。Agent 的"Session"可能跨越一个长时间运行的工作流，派生并行的子任务，并且超越任何合理的人类 Session 模式，同时仍然需要与人类相同的有限范围、可撤销的访问权限。

先看经典流程，简化到四个关键跳跃：

一个人类决策点，就在开始，只有一次从应用到资源的跳跃。很简单。

现在看一个 Agent 委托链实际需要什么。人类仍然只在事前决策一次，但下游的一切都必须通过 token 来携带和执行，而不是另一次点击：

顶部同样是单次人类决策。但在它下面，有两个额外跳跃是人类从未实时看到或批准的，而且每一个都必须通过它携带的 token 自我证明，而不是通过盯着屏幕的人。

真正有用的做法

好消息是，我们不是从零开始。RFC 8693，OAuth 2.0 Token Exchange 规范，已经为我们提供了一个"代表" token 的模式，其中一方可以为一个更窄的、下游的 token 交换 token，同时保留一个"谁在为谁行动"的链条。如果团队真正使用它，而不是为每个 Agent 随手生成一个新的静态密钥，这几乎完美地映射到 Agent 委托场景。

实践中大致是这样的：

# Agent 请求一个更窄的、短生命周期的 token 来调用下游 API，
# 代表最初委托任务的用户。

response = requests.post(
    token_endpoint,
    data={
        "grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
        "subject_token": agent_session_token,
        "subject_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
        "scope": "calendar.read",          # 比 Agent 自身范围更窄
        "audience": "calendar-service",    # 明确的下游目标
    },
)

downstream_token = response.json()["access_token"]
# 这个 token 应该是短生命周期的、可审计的、可追溯的
# 追溯到执行操作的 Agent 和委托任务的人类。

将其与携带明确"代表某人行事"字段的基于 JWT 的声明（RFC 7519）结合，你得到的 token 就能真正回答审计员六个月后会问的问题：这个操作是哪个 Agent 执行的，凭谁的授权，访问范围是什么？

围绕 MCP 服务器的身份验证模式也有真正的进展，因为 MCP 正在迅速成为 Agent 与工具和数据源对话的方式。值得密切关注这个领域，因为无论哪个模式在那里胜出，很可能都会成为 Agent 到工具身份验证的行业默认。

OAuth 没有坏；只是对这种新类型的参与者来说不完整。解决方案不是抛弃它，而是扩展它：事前同意而非交互式同意，token 交换处理分层身份而非单一 flat token，短生命周期有限范围授权而非静态密钥在环境文件中躺六个月。

如果你的 Agent 架构仍然把 Agent 当作"另一个 OAuth 客户端"处理，拿着一个长期有效的密钥，那么距离你因为一次事故而深刻理解 OAuth 中人类专属假设的意义就只差一步了。