摘要

  • DPoP 改变的是不记名令牌的一项性质：拿到令牌字符串还不够，请求方还须用与令牌绑定的私钥签出一份新证明。
  • 证明只覆盖有限上下文，包括方法、去掉查询和片段后的目标 URI、签发时间、唯一标识、令牌散列，以及服务器要求时的 nonce；它既不是整份 HTTP 请求的签名，也不是操作许可。
  • 资源服务器仍须独立验证令牌签发者、受众、期限、状态和权限，协调重放记录，还原正确的外部 URI，并根据主体、客户端、资源、动作与对象现状作出最终授权。

一次被挡住的令牌盗用

设想一枚访问令牌意外出现在排障日志中。若它是 Bearer 令牌，字符串本身就是能力：任何得到它的人，只要能到达接受该令牌的资源服务器，就能在令牌失效或被撤销前使用它。泄露发生在哪里并不重要，出示者是谁也不重要。

现在这枚令牌采用 DPoP。攻击者把字符串复制到另一台机器，请求却在入口处失败。资源服务器不仅要求 Authorization: DPoP 中的令牌，还要求一份由绑定私钥签出的 DPoP 证明。攻击者没有那把私钥；换一把密钥签名，公钥指纹对不上；把截获的旧证明再送一次，又会在方法、URI、时间、nonce 或重放检查处落败。

这是实质性的安全改进：单独外泄的令牌不再足以离开原有签名环境执行请求。

但随后，真正的客户端提交了请求。它持有正确密钥，签名有效，htm 与方法一致，htu 与目标一致，ath 与令牌一致，证明也足够新。所有 DPoP 检查都显示绿色，资源服务器仍然拒绝。

原因可能是令牌的受众是另一个服务；它只有读取权限，却请求删除密钥；账户在令牌签发后已被冻结；一次性操作已经完成；或者对象已经进入任何客户端都不得修改的状态。这里没有一项说明 DPoP 失效。它只说明“这个请求方能使用与令牌绑定的密钥”，而授权系统回答的是“它现在能否让这个资源发生这种变化”。

从持有字符串到证明发送方

RFC 6750 给 Bearer 令牌的定义十分直接：持有令牌的一方便能使用它，无须证明自己掌握某个加密密钥。TLS、安全存储、短有效期和受众限制都能减少泄露概率或缩小损失，却不改变字符串在接受边界内可被转交使用的本质。

RFC 9449 在应用层加入另一道条件。客户端生成一对非对称密钥，向授权服务器申请令牌时提交签名证明；授权服务器可以把发出的访问令牌或刷新令牌绑定到公钥的 JWK 指纹。访问受保护资源时，客户端同时提交令牌和一份新签出的证明，资源服务器确认两者指向同一把密钥。

因此，只窃取令牌值而没有密钥材料或可调用的签名接口，不再得到完整凭据。RFC 9700 也把发送方约束、受众限制和最小权限分别列为抵御令牌滥用的重要手段。三者并列本身就是提醒：其中任何一项都不能吞掉另外两项。

JWK 指纹是按规范化公钥字段计算出的确定性摘要。它可以准确指向某份公钥表示，却不会自动回答密钥由谁生成、目前由谁控制、用户是否同意此次操作、设备是否可信，或企业是否授予了相应职责。密码学上清晰的标识符，不能被顺手抬升为人员、组织或授权的替身。

证明到底证明了什么

一份 DPoP 证明是作为 JWS 签名的 JWT。受保护头部需要明确给出 typ: dpop+jwt，使用本地策略允许的非对称 alg，并携带不含私钥材料的公钥 jwk。这些字段让接收端知道它处理的是 DPoP，而不是把任意签名 JWT 送进一个“验签通过即可”的通用分支。RFC 8725 所强调的类型、算法、签发者和受众隔离，在这里同样重要。

基础载荷有四个关键声明。htm 是 HTTP 方法；htu 是目标 URI，但明确排除查询和片段；iat 记录证明生成时间；jti 是应具有足够不可预测性的证明标识。资源请求还需要 ath，即对所出示访问令牌精确值计算的 SHA-256 散列。若服务器发出 DPoP-Nonce 挑战，下一份证明还须带上该 nonce。

这些字段组成了一条窄而有用的链：签名证明密钥被实际调用；htm 和 htu 把证明约束到一类目标请求；iat 提供时间上下文；jti 为接收端查重提供键；ath 防止同一证明被换配另一枚令牌；nonce 则能削弱提前批量生成证明的价值。

字段存在并不等于规则执行。接收端必须拒绝多个 DPoP 头、畸形 JWT、错误类型、不允许的算法、无效签名和携带私钥的 JWK；还要比较当前方法与 URI，限定时间窗口，重算 ath，比对令牌中绑定的指纹，并执行自己发出的 nonce 规则。一个库能解码 JWT，只是证据链的起点。

三种绑定不能缩成一个开关

第一种是令牌到密钥的绑定。授权服务器把 JWK 指纹写入令牌确认信息，通常表现为 cnf.jkt。资源服务器需要把这个值与当前证明公钥计算出的指纹比较。

第二种是证明到令牌的绑定。ath 对本次请求携带的访问令牌原值作承诺，阻止攻击者把一份证明挪到另一枚令牌上。它不验证受众、权限、期限或撤销状态。

第三种可以更早发生。授权请求中的可选参数 dpop_jkt 能把授权码绑定到预期证明密钥。否则，截获授权码并掌握其他兑换条件的攻击者，可能用自己的密钥提交证明，让最终令牌“正确”地绑定到错误的发送方。授权码到密钥的绑定补上的是这一段替换路径；它不替代 PKCE，也不替代客户端认证或资源所有者授权。

所以，“已启用 PoP”这样的总开关缺少诊断价值。签发阶段、授权码兑换阶段和资源访问阶段可能分别正确或分别断裂。审计证据必须保留具体绑定名称、输入和比较结果。

被覆盖的请求比业务命令小

htm 能阻止把为 GET 签出的证明直接当作 DELETE；htu 能阻止把一个目标的证明搬到另一个目标。这两项约束非常有用，但它们描述的并不是完整业务命令。

规范中的 htu 不含查询和片段。若系统把账户号放在 /transfer?account=A 中，改为 account=B 并不会改变基础 DPoP 证明覆盖的 URI。JSON 正文中的金额、收款人或发布版本也通常不在签名范围内；任意请求头同样不会因为 DPoP 自动获得完整性保护。

这不是标准暗藏的缺陷，而是机制的刻意分工。DPoP 是发送方约束，不是 HTTP Message Signatures、交易授权对象或业务幂等键的替代品。RFC 9110 定义 HTTP 语义，应用则必须决定查询、正文和对象状态意味着什么。真正执行命令的服务仍应对将要产生的后果授权。

代理链让 htu 更容易暴露责任空白。客户端看到的是外部 scheme、authority 和 path；网关可能终止 TLS、改写路径并转发内部 host。下游若从错误一侧还原 URI，合法客户端会被拒绝；为减少报错而接受多个松散候选，又可能扩大可重放边界。外部请求上下文、可信转发链与规范化规则需要明确的持有者和可复现测试。

新鲜度是一套分布式状态

iat 和 jti 提供了实施重放控制的材料，却不会自行阻止重放。服务器要决定允许多老的证明、容忍多少时钟偏差、以什么键保存已使用记录、保留多久，以及哪些副本共享这份状态。

若一份证明在上海区被记录，而法兰克福区尚未看到记录，同一请求就可能在两处通过。若“检查是否出现”和“写入已使用”不是原子操作，两份并发副本都可能读到未使用。若 nonce 长期不换或跨过多客户端共用，挑战便从实时证据退化为装饰。

授权服务器 nonce 与资源服务器 nonce 也不能互换。多服务客户端必须按签发者保存挑战，否则本应提高新鲜度的字段会变成跨域故障来源。

更重要的是，拒绝旧证明不等于业务只执行一次。客户端完全可以为两次重试各签一份新证明；两份在密码学上都唯一。若第一次已经扣款但响应丢失，第二次是否再次扣款，要靠应用幂等性、交易状态和提交记录决定。DPoP 的重放表不能替代业务账本。

密钥持有既不是身份，也不是同意

证明中的公钥只告诉接收端哪把密钥验证了签名。它不说明这把密钥属于注册客户、某个自然人或合规设备，也不说明用户认可当前交易。机密客户端认证可以与 DPoP 同时存在；二者回答不同问题。访问令牌承载由签发者定义的授权上下文；证明约束发送方；资源应用作最终决策。

浏览器尤其容易制造过度承诺。RFC 10017 讨论的不可导出密钥，可以让恶意代码难以把令牌和密钥复制到另一台机器后继续使用。但已经在应用同源上下文中执行的代码，仍可能调用可用的签名能力、在现有会话中发送请求，甚至启动新的授权流程。“不能导出”并不等于“不能被错误代码调用”。

如果攻击者同时拿到令牌与私钥，或者长期控制了签名接口，发送方约束就被穿透。硬件密钥和不可导出策略改善密钥保管，却不会把一个受控客户端变回可信主体。

让证据跑完整条接受路径

IANA 已登记 DPoP 与 DPoP-Nonce HTTP 字段，也维护相关 OAuth 参数。这些公共名称让不同实现能对话，却不能证明某个生产部署在各层执行了同一语义。

运行证据应从签发一路跟到业务提交：保留经过隐私处理的证明散列、公钥指纹、令牌类型、ath 比较、外部与内部规范化 URI、证明年龄、nonce 签发方、重放记录结果、令牌签发者与受众、权限判断、资源策略版本以及最终提交标识。绝不记录原始访问令牌或私钥。

负向测试要跨组件展开：只有被复制令牌而无密钥；正确密钥配错误令牌；过期证明；重复 jti；错误方法；路径改写；缺失或来自别处的 nonce；错误受众；权限不足；账户冻结；操作已完成。能解释每一次拒绝发生在哪一层，才比一枚“DPoP 已启用”徽章更接近真实控制。