谷歌新增了一项安全功能，将用于延续应用服务访问权限的刷新令牌绑定到应用持有的加密密钥。接入谷歌服务的开发者可以减少仅窃取令牌后重复使用的攻击，但实际调用服务所用的访问令牌方式不变。
1. 优先保护长期使用的凭据
刷新令牌（refresh token）是用于获取新访问令牌的长期凭据。访问令牌（access token）是向服务发起请求时使用的凭据，谷歌将其通常有效期描述为不超过 1 小时。
新增的 DPoP 是 RFC 9449 定义的应用层安全机制。它将令牌与客户端生成的公私钥对关联起来。如果令牌是入场券，对应的私钥就是用于证明持有者身份的另一把钥匙。仅泄露令牌无法重复使用。
谷歌仅将这种绑定应用于刷新令牌。这一选择旨在保护持续获取新访问权限的通道，降低攻击者利用被盗凭据长期冒充用户的风险。
2. 避免每次调用都验证的成本
访问令牌仍采用持有者即可使用的 Bearer 方式。谷歌解释，在请求量大的 API 中，每次验证非对称签名都会增加计算负担、延迟和扩展成本。这是设计依据，公告未提供性能量化对比的测量结果。
收益与成本分布在不同环节。在保护长期凭据的同时，避免每次服务调用都验证持有证明的负担，但客户端新增了安全生成和存储密钥以及生成证明的责任。这意味着除现有令牌管理外，还需考虑加密运算和存储限制。
3. 引入时需要证明生成流程
除生成密钥外，客户端还必须严格处理时间信息和名为 nonce 的一次性值。需要准确构造包含请求信息的声明和标头，并生成承载持有证明的 JWT。这些处理会加入原本只需发送令牌的流程。
公告没有提供实现代码示例。谷歌给出了单独的接入指南和辅助实现的 SKILL.md 文档。因此，仅凭公告无法确定具体请求格式或库的用法。
4. 经过中间服务器也能保持绑定
谷歌援引了 RFC 9700 中关于刷新令牌保护的讨论和浏览器应用相关标准草案。它建议在浏览器专用后端、令牌中继后端和基于浏览器的客户端这三种模型中，对刷新令牌施加持有者约束。
在传输层绑定令牌的 mTLS，其连接可能在云代理或负载均衡器处终止或中断。相比之下，DPoP 在请求标头层面工作。谷歌解释，这一特性也适用于经过多个中间服务器的智能体架构。
5. Cookie 保护与智能体委托是独立问题
普通 Web 应用的会话 Cookie 不在此次功能的保护范围内。谷歌与 Web 孵化器社区组正在开发将 Cookie 绑定到设备硬件的 DBSC。这意味着 API 令牌和浏览器会话需要各自独立且互补的保护。
智能体之间的任务委托也值得注意。接手任务的智能体若没有前一个智能体的私钥，就无法代其签署持有证明。共享私钥违背了这种安全机制的原则。
面向消费者的身份验证端点 oauth2.googleapis.com 不支持令牌交换。谷歌建议在多智能体或联合云任务中考虑 Google Cloud Secure Token Service。这一路径让中间智能体将上游令牌换成绑定到自身密钥的短期联合令牌。
此次变更是在保持服务调用方式不变的同时加强长期凭据保护，是否引入的关键在于能否承担密钥管理和委托路径的要求。