TOPIC COLLECTION
Google OAuth支持DPoP了：refresh token被偷也用不了，接Gmail、Drive API的应用和AI智能体要不要改、怎么改
Google在2026-10-15宣布OAuth平台支持DPoP（RFC 9449）。它只给refresh token做发送方绑定：令牌和客户端生成的密钥对绑在一起，泄露后没有私钥无法重放；access token仍是普通Bearer。DPoP为可选项，Google建议公共客户端、访问高敏感数据或有合规要求的应用采用。
资料更新：2026-10-19
依据Google Developers Blog《Announcing DPoP Support for Google OAuth: Securing Refresh Tokens》（2026-10-15）、Google Identity文档《OAuth 2.0 for Desktop Apps》《Best Practices》及DPoP Adoption Guide。本站未在生产环境接入，代码细节以官方文档为准。核查2026-10-19（新加坡时间）。
主题标签：Google OAuth、DPoP、refresh token、RFC 9449、API安全、MCP
做过Google登录、接过Gmail或Drive API的人都知道，refresh token是整套授权里最值钱的东西。拿到它，就能一直换新的access token，用户不在线也行。
问题是，它一直是「谁捡到算谁的」。被盗号木马扒走、被中间人截到，攻击者直接拿去用，Google那边分不出真假。
2026-10-15，Google在开发者博客宣布OAuth平台支持DPoP，专门补这个洞。
DPoP一句话讲明白
DPoP全称Demonstrating Proof-of-Possession，标准号RFC 9449。客户端自己生成一对非对称密钥，换令牌时附上一个用私钥签名的JWT证明。Google把发出的令牌和这个公钥绑在一起。
以后再用这个令牌，必须再拿私钥签一次证明。令牌被偷了，攻击者手里没有私钥，就用不了。
Google的实现有个关键取舍
只绑定refresh token，access token还是普通Bearer。
Google博客解释得很清楚：验证非对称签名很耗CPU，如果Gmail、Calendar、Drive这些高并发API每次请求都要验一遍DPoP证明，网关层的开销和延迟都扛不住。access token通常一小时内就过期，被偷的窗口有限；refresh token能无限续命，才是真正要保护的。
| refresh token | access token | |
|---|---|---|
| 是否DPoP绑定 | 是（启用DPoP时） | 否，仍是Bearer |
| 典型有效期 | 长期 | 通常1小时内 |
| 泄露后果 | 绑定后无私钥无法重放 | 过期前可被使用 |
谁应该先改
DPoP在Google这里是可选的，不改也不会坏。Google的最佳实践文档建议这三类应用优先采用：
- 公共客户端，比如单页应用、桌面或手机上装的应用，refresh token更容易被扒；
- 访问高敏感数据或高价值API的应用；
- 合规要求必须使用发送方约束令牌的场景。
我再补一类：替用户长期操作Google账号的AI智能体和MCP服务。这类服务手里攒着大量用户的refresh token，一旦数据库泄露，就是批量失守。前阵子OpenCode控制台泄露事件已经提醒过，密钥类数据是攻击者最爱的目标。
接入时要改哪几步
按Google文档，改动集中在令牌端点https://oauth2.googleapis.com/token的两次请求上。
1. 生成并保管密钥对。客户端生成非对称密钥（如ES256）。Google建议私钥放在拷不走的地方：TPM、Secure Enclave或其他硬件密钥库。服务端应用至少要放在专门的密钥管理服务里，别和令牌存在同一张表。
2. 授权码换令牌时带上DPoP头。请求里加一个DPoPHTTP头，值是证明JWT。注意它是头，不是表单参数。返回的令牌就和这个公钥绑定了。
3. 每次刷新都生成新证明。用refresh token换新令牌时，必须用同一把私钥重新签一个全新且唯一的证明。证明里要有htm（HTTP方法）、htu（请求地址）、iat（时间）、jti（唯一ID），并且和这次请求对得上。
4. 处理nonce。Google可能在响应头里返回DPoP-Nonce，客户端要缓存，下一次证明的nonce字段里带上。按Google的接入指南，如果收到要求nonce的错误，用新nonce重签后重试。
调试时可以用JWT.io看证明的头和载荷对不对，用Postman手动构造请求。Google还提供了一份DPoP接入的SKILL.md，可以丢给Claude Code这类编程智能体参考着改代码。
它管不到的地方
浏览器会话cookie。DPoP只管OAuth令牌，不管网站登录cookie。cookie被盗号木马偷走的问题，Google和WICG在推另一套方案DBSC（设备绑定会话凭证），还在开发中。
授权码阶段。那一段靠PKCE保护。Google的说法是两者配合：PKCE护住授权码，DPoP护住refresh token。
多智能体转委托。A智能体把任务交给B，B再去调Google API，B没法替A签DPoP证明，共享私钥又违背DPoP的初衷。Google消费级OAuth端点不支持RFC 8693令牌交换，官方建议走Google Cloud的Secure Token Service（STS），让B换一个绑定自己密钥的短期联合令牌。
用Auth0、Okta这类身份平台的
如果你的应用不直接对接Google，而是经过Auth0、Okta等身份平台中转，要看平台是否已经支持把Google的DPoP能力用起来，以及它自身对DPoP的支持情况，以各平台文档为准。
个人用户这边能做的不多：别在来路不明的电脑上登录Google账号，定期去账号的「第三方应用」页面清理不用的授权，密码交给1Password这类管理器。更多开发工具见开发工具分类和开发文档分类。
改造前先盘点这几件事
你的应用里有多少个地方在存Google的refresh token？很多老项目除了主数据库，还有日志、缓存、备份里残留着令牌。先把这些地方找全。
令牌和用户的对应关系是否清楚？绑定DPoP后，每个令牌背后多了一把私钥要管理，最好按用户或按设备建立清晰的映射，私钥轮换时才知道该让哪些用户重新授权。
上线策略可以分批：新授权的用户先走DPoP流程，老用户的令牌保持原样，等他们下次重新登录时自然迁移。这样不会一次性逼所有人重新授权。
常见疑问
已经发出去的refresh token会自动绑定吗？不会。绑定发生在你带着DPoP证明换令牌的那一刻，老令牌要等用户重新授权或你按新流程重新获取。
启用后返回的token_type是什么？Google文档写明，使用DPoP时返回的token_type仍是Bearer，因为access token本身不绑定。
私钥丢了怎么办？绑定在这把私钥上的refresh token就用不了了，只能让用户重新授权。所以私钥的备份和轮换策略要先想好。
来源与核查日期
- Google Developers Blog：Announcing DPoP Support for Google OAuth（2026-10-15）
- Google Identity：OAuth 2.0 for Desktop Apps（含DPoP请求说明）
- Google Identity：OAuth Best Practices
核查日期：2026-10-19（新加坡时间）。参数与错误码以Google官方文档最新版本为准。
