2. Objectives (目标)

2. Objectives (目标)

DPoP 的主要目的是通过在颁发时将令牌绑定到公钥，并要求客户端在使用令牌时证明拥有相应的私钥，从而防止未经授权或非法的当事方使用泄漏或窃取的访问令牌。这将令牌的合法发送者限制为仅拥有私钥的当事方，并使接收令牌的服务器更加确信发送者已获得合法授权使用该令牌。

因此，通过 DPoP 进行发送者约束的访问令牌与典型的 bearer 令牌形成对比，后者可由拥有此类令牌的任何一方使用。尽管通常存在保护措施以防止意外泄露 bearer 令牌，但在协议或软件堆栈的其他层中，由于漏洞和实现问题，已经出现了不可预见的泄漏途径（例如，Compression Ratio Info-leak Made Easy (CRIME) [CRIME]、Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH]、Heartbleed [Heartbleed] 和 Cloudflare 解析器错误 [Cloudbleed]）。针对 OAuth 实现本身的令牌窃取攻击也已发表了很多（[GitHub.Tokens] 只是一个备受瞩目的例子）。DPoP 提供了一种通用的纵深防御，以应对意外的令牌泄漏的影响。然而，DPoP 不能替代安全传输，必须始终与 HTTPS 结合使用。

典型 OAuth 协议交互的本质使得客户端必须向其访问的受保护资源披露访问令牌。[SECURITY-TOPICS] 中的攻击者模型描述了这样一种情况：受保护资源可能是伪造的、恶意的或已受损的，并利用收到的令牌针对其他受保护资源进行未经授权的访问。受受众限制的访问令牌（例如，使用 JWT [RFC7519] aud 声明）可以防止这种滥用。然而，实践证明，对于许多部署来说，这样做过于繁琐（尽管有 [RFC8707] 等扩展）。对访问令牌进行发送者约束是一种更稳健、更直接的机制，可以防止在不同端点重放令牌，而 DPoP 是一种可行的应用层手段。

由于存在跨站脚本 (XSS) 的可能性，基于浏览器的 OAuth 客户端在保护令牌方面带来了额外的考虑。最直接的基于 XSS 的攻击是攻击者窃取令牌并完全独立于合法客户端自行使用。被盗的访问令牌用于访问受保护资源，被盗的刷新令牌用于获取新的访问令牌。如果私钥是不可导出的（如 [W3C.WebCryptoAPI] 所允许的那样），DPoP 使窃取的令牌本身无法使用。

XSS 漏洞还允许攻击者在基于浏览器的客户端应用程序的上下文中执行代码，并通过客户端间接恶意使用令牌。该执行上下文有权使用签名密钥；因此，它可以生成 DPoP 证明以与令牌结合使用。在这个应用层，除了通常防止 XSS 之外，很可能没有切实可行的防御措施来应对这种威胁；因此，这被认为超出了 DPoP 的范围。

在基于浏览器的客户端应用程序上下文中执行的恶意 XSS 代码也可以使用未来的时间戳值创建 DPoP 证明，并将其与令牌一起窃取。这些被盗的工件以后可以独立于客户端应用程序使用，以访问受保护资源。为了防止这种情况，服务器可以选择性地要求客户端在证明中包含攻击者无法预测的服务器选择的值（Nonce）。在没有可选 Nonce 的情况下，预先计算的 DPoP 证明的影响受到证明在访问受保护资源时绑定到访问令牌的限制。因为实际上无法创建覆盖尚不存在的访问令牌的证明，所以使用窃取的刷新令牌和预先计算的证明获得的访问令牌将无法使用。

第 11 节讨论了其他安全注意事项。