AI智能体的OAuth授权：四大扩展能覆盖什么，又留下哪些缺口

为什么AI智能体需要专门的OAuth扩展

当AI智能体代替用户访问第三方API时，传统的OAuth流程暴露出一个根本问题：授权令牌通常绑定的是“用户+客户端应用”，而不是“用户+具体智能体实例+它正在执行的具体任务”。这意味着一个被授予了宽松权限的智能体，可能在用户不知情的情况下调用远超预期的资源。

业界频繁引用的四个OAuth扩展——RAR（Rich Authorization Requests）、DPoP（Demonstrating Proof of Possession）、CIMD（Client ID Metadata Document）和Transaction Tokens——被视作填补这一缺口的候选方案。但理解它们各自“绑定”了什么，比笼统地说“用OAuth解决”更有价值。

OAuth 2.0 是业界最广泛使用的授权框架，其核心思想是让用户通过授权服务器向第三方客户端颁发访问令牌，而不必共享密码。标准 OAuth 的授权粒度通常以 scope 字符串表示，令牌绑定的是“用户 + 客户端应用”这一对关系。这种设计在传统 Web 应用中运作良好，因为客户端的行为边界相对固定、可预先审查。但 AI 智能体的行为具有动态性和自主性，同一个客户端可能代表不同用户执行多种任务，标准 OAuth 的粗粒度绑定无法表达“这次授权具体用于什么操作”。正是在这一背景下，IETF 社区提出了若干 OAuth 扩展草案，试图在令牌中注入更细粒度的上下文信息。

四个扩展各自绑定了什么

RAR：把授权范围写得更细

RAR允许客户端在授权请求中携带结构化的authorization_details，用JSON描述具体要执行的操作，而不是只给一个粗粒度的scope字符串。对AI智能体而言，这意味着可以声明“读取某用户的日历事件，时间范围为一周内”，而不是笼统的“calendar.read”。

RAR的价值在于让授权意图可审查、可限制。但它本身不验证请求方身份，也不阻止令牌被挪用——它只是把“要做什么”写清楚了。

DPoP：把令牌绑定到持有者

DPoP通过让客户端证明持有私钥，将访问令牌绑定到特定的密钥对。即使令牌被截获，攻击者没有对应私钥也无法使用。对运行在不可信环境中的智能体来说，这降低了令牌泄露后的滥用风险。

不过DPoP绑定的是“谁在持有令牌”，而非“持令牌者在代表谁执行什么任务”。一个合法持有DPoP密钥的智能体，仍然可以在授权范围内做任何事。

持有者令牌（Bearer Token）是 OAuth 2.0 默认的令牌类型，其特点是“谁持有谁使用”，不验证请求方身份。一旦令牌泄露——无论是通过日志、中间人攻击还是不可信运行环境——攻击者即可直接冒用。DPoP 属于发送方约束令牌（Sender-Constrained Token）机制，客户端在令牌请求和资源请求时都需附带一个用私钥签名的 JWT 证明，授权服务器将公钥指纹嵌入访问令牌，资源服务器据此验证请求方确实持有对应私钥。与之类似的还有 mTLS 绑定证书的方案，但 DPoP 不依赖双向 TLS，部署门槛更低，因而更适合运行在云原生或边缘环境中的智能体。

CIMD：让客户端身份可发现、可验证

CIMD用托管在HTTPS上的元数据文档来描述客户端身份，替代静态的client_secret。这让授权服务器能够动态获取客户端的声明信息，也便于智能体框架在规模化部署中管理身份。

它的贡献在于身份层面的可验证性，但同样不涉及单次任务的上下文约束。

传统 OAuth 客户端注册依赖静态的 client_id 和 client_secret，密钥需要预先配置和保管，在规模化部署中容易成为运维负担和泄露风险点。CIMD 的思路是让客户端身份以 HTTPS 托管的元数据文档形式对外发布，授权服务器通过解析该文档动态获取客户端的名称、重定向 URI、支持的授权类型等信息，从而减少对预共享密钥的依赖。这一机制与 OAuth 生态中已有的动态客户端注册（DCR）和客户端断言（private_key_jwt）形成互补，但 CIMD 更强调身份的可发现性和可验证性，适合智能体框架在多租户、多实例场景下统一管理客户端身份。

Transaction Tokens：为单次交易签发凭证

Transaction Tokens的思路是针对一次具体交易签发短时效令牌，把用户身份、交易内容和请求方绑定在一起。这是四个方案中最接近“任务级授权”的机制，但它依赖交易发起方与授权方之间的额外协调，生态支持尚不成熟。

三个尚未解决的问题

据原文分析，这四个扩展组合起来仍留下三处缺口：

第一，跨智能体委派的链路追溯。 当一个智能体把任务转交给另一个智能体时，现有扩展没有标准化方式表达“原始用户授权经过了哪些中间方”。DPoP证明了当前持有者，但无法还原委派链。

第二，授权意图与实际行为的一致性校验。 RAR写清了意图，但资源服务器端缺少通用机制去比对“令牌声明的操作”与“实际请求的操作”是否一致。这需要资源服务器主动实现校验逻辑，而非协议层保证。

第三，长时任务的令牌生命周期管理。 AI智能体执行的任务可能持续数小时甚至更久，而短时效令牌需要不断刷新。刷新过程中的权限降级、任务中断恢复等场景，四个扩展都没有给出统一答案。

对开发者的实际含义

如果你的系统正在接入AI智能体，把RAR和DPoP组合使用是目前较务实的选择：前者约束授权范围，后者降低令牌泄露风险。CIMD适合客户端规模较大、需要动态管理的场景。Transaction Tokens则更适合金融等高价值单次操作，但要做好自行补齐协调逻辑的准备。

需要清醒认识的是，这四个扩展解决的是OAuth层面的“绑定”问题，而智能体授权的完整链路还涉及任务编排、审计日志和跨域信任，这些仍需要应用层自行设计。