谷歌OAuth 2.0启用DPoP：刷新令牌如何防窃取重放？
谷歌 OAuth 平台最近新增了对 Demonstrating Proof-of-Possession（DPoP）的支持，这是一种 OAuth 2.0 安全机制，用于缓解令牌盗取和重放攻击。 传统的 OAuth 持有者令牌（Bearer Token）遵循“谁拿到、谁可用”的模式，容易遭到信息窃取恶意程序（例如 RedL
过去那种 OAuth 持有者令牌，逻辑就是“谁拿到、谁就能用”。碰上 RedLine、NodeStealer 这类专门偷信息的恶意程序，或者中间人攻击者（AiTM），这种令牌很容易被钻空子。
DPoP 的应对办法是用密码学，把令牌跟客户端自己生成的一对非对称密钥绑在一起。私钥一直留在客户端手里，所以令牌即使被偷走，攻击者拿不到对应私钥，也没法重放。
谷歌 OAuth 平台的做法是只给刷新令牌启用 DPoP，寿命短的访问令牌照旧用标准持有者令牌。原因在于，长效刷新令牌是“长期在线身份冒用的主要攻击入口”；要是访问令牌也上 DPoP，每一次请求都得付一次非对称密码校验的开销。
不过启用 DPoP 之后，客户端要多做几件事：生成加密密钥，把时间戳和随机数处理对，构造合适的 HTTP 请求头，还要生成所需的 DPoP 证明 JWT。
DPoP 护住的是 API 令牌，标准的 Web 应用会话 Cookie 它管不了，Cookie 照样可能被 Infostealer 恶意软件盯上。针对 Cookie 被盗，谷歌和 Web 孵化器社区组（WICG）正在推进设备绑定会话凭证（Device-Bound Session Credentials，DBSC）。
DBSC 跑在浏览器和网络层，靠密码学把浏览器的会话 Cookie 绑到设备硬件上，比如 TPM。DPoP 加 DBSC，合起来就是一套针对 API 和 Web 用户会话凭证盗窃的纵深防御。
谷歌同时说明，DPoP 不适合多智能体工作流。一个智能体要把任务委托给另一个智能体，就得让第二个智能体代表第一个去签名请求，那它必须拿到第一个智能体生成的私钥，这跟 DPoP 的规则相冲突。谷歌给出的替代方案是谷歌云安全令牌服务（STS）。
走 STS 路由委托时，中间智能体可以把上游令牌换成新的短期联邦令牌，新令牌绑定在它自己的本地密钥对上。这样整条智能体链上的发送者约束都保住了，私钥也不用暴露。
DPoP 私钥存在客户端，说到底安全性取决于客户端自身。Dhruv Agnihotri 论证过，浏览器里跑的单页应用（SPA）没法完全防住密钥被滥用。所以 IETF 面向浏览器端应用的指南推荐 Backend-for-Frontend 模式，把令牌和加密密钥放到浏览器之外。Agnihotri 还提出了一种_零持久化方法_，服务器端基础设施不可用的时候或许能派上用场。
