DPoP

DPoP绑定的是令牌持有者身份，而非令牌持有者代表谁执行什么任务。

对AI智能体接入系统，组合使用RAR和DPoP是当前较务实的选择。

四个扩展均未给出长时任务刷新过程中权限降级、任务中断恢复等场景的统一答案。

四个OAuth扩展组合后仍无法标准化表达跨智能体委派的链路追溯。

DPoP不依赖双向TLS，部署门槛低于mTLS绑定证书方案。

标准的 DPoP 规范（RFC 9449）同时覆盖访问令牌和刷新令牌，而 Google 当前的选择是仅对刷新令牌强制绑定，访问令牌仍为 Bearer。

Google 近期为 OAuth 刷新令牌引入了 DPoP（Demonstrating Proof of Possession）绑定机制，将刷新令牌与客户端密钥绑定，而访问令牌仍保持 Bearer 形式。

授权服务器在签发令牌时会将客户端公钥的指纹（jkt）嵌入令牌（通常通过 cnf 声明），使用刷新令牌兑换新访问令牌时必须同时提供有效的 DPoP 证明，服务器验证签名、jkt 匹配以及请求参数一致性。

RFC 9449（OAuth 2.0 Demonstrating Proof of Possession）是 IETF 发布的标准规范，定义了 DPoP 的完整框架，包括对访问令牌和刷新令牌的绑定、nonce 机制、错误响应等。

Google 的 DPoP 支持面向能够安全持有私钥的客户端，例如服务器端应用、原生应用（利用安全存储）等；对于无法安全存储密钥的公共客户端（如纯浏览器端应用），DPoP 的适用性有限。

实施 DPoP 的主要步骤包括：生成非对称密钥对、在刷新令牌请求中附加 DPoP 证明（JWT）、确保令牌端点验证该证明。

DPoP 证明与请求绑定，开发者需要确保时间同步和 nonce 处理正确，以避免重放攻击。

DPoP 对刷新令牌的保护降低了令牌泄露后的影响范围，但访问令牌仍为 Bearer，在有效期内泄露的访问令牌仍可被滥用。

客户端的密钥管理本身成为新的攻击面，如果私钥保护不当，DPoP 的收益将大打折扣。

DPoP是IETF OAuth工作组定义的机制，客户端生成非对称密钥对每个HTTP请求签名，资源服务器验证签名，使令牌被窃取后攻击者无私有密钥也无法使用。

若客户端生态尚未支持 DPoP，强制启用可能导致连接中断

DPoP 是一种将令牌与客户端密钥绑定的机制，要求客户端在每次请求时用私钥对请求签名以证明持有绑定密钥

DPoP 证明是一个由私钥签名的 JWT，包含 HTTP 方法、目标 URL、时间戳以及唯一随机值 jti，令牌颁发时绑定客户端公钥指纹

对已有 MCP 部署，建议采用渐进式迁移：先支持而非强制 DPoP，观察客户端适配情况再逐步收紧策略

启用 DPoP 后，MCP 服务器需要在验证访问令牌的同时校验 DPoP 证明头，并具备解析签名、验证密钥绑定关系及防重放（nonce 或时间戳）的能力