11. Security Considerations (安全考虑)

在 DPoP 中，防止在不同端点重放令牌（参见第 2 节）是通过根据 [RFC6125] 对服务器的身份验证以及将 DPoP 证明绑定到特定 URI 和 HTTP 方法来实现的。但是，DPoP 的保护性质与基于 TLS 的方法（如 OAuth 双向 TLS [RFC8705] 或 OAuth 令牌绑定 [TOKEN-BINDING]）有所不同（另请参见第 11.1 节和第 11.7 节）。基于 TLS 的机制可以利用 TLS 层和应用层之间的紧密集成来实现强大的消息完整性、真实性和重放保护。

11.1. DPoP 证明重放

如果对手能够获取 DPoP 证明 JWT，该对手可以在同一端点重放该令牌（HTTP 端点和方法通过 JWT 中的相应声明强制执行）。为了限制这种情况，服务器必须仅在 DPoP 证明创建后的有限时间内接受它们（最好仅在秒或分钟量级的相对较短时间内）。

在目标 URI 的上下文中，服务器可以在接受相应 DPoP 证明 JWT 的时间窗口内存储每个 DPoP 证明的 jti 值，以防止同一 DPoP 证明被多次使用。对以前见过 jti 值的同一 URI 的 HTTP 请求将被拒绝。如果严格执行，这种一次性检查提供了针对 DPoP 证明重放的非常强大的保护，但在实践中并不总是可行的，例如，当单个端点后的多个服务器没有共享状态时。

为了防止内存耗尽攻击，跟踪 jti 值的服务器应拒绝具有不必要大的 jti 值的 DPoP 证明 JWT，或者仅存储其哈希值。

注意：为了适应时钟偏移，服务器可以接受 iat 时间在合理不久将来的 DPoP 证明（秒或分钟量级）。由于服务器和客户端之间的时钟偏差可能很大，服务器可以通过使用包含服务器时间的服务器提供的 nonce 值来限制 DPoP 证明的生命周期，而不是将客户端提供的 iat 时间与服务器时间进行比较。即使面对任意大的时钟偏差，以这种方式创建的 nonce 也会产生相同的结果。

服务器提供的 nonce 是进一步降低 DPoP 证明重放成功机会的有效手段。与加密 nonce 不同，客户端多次使用相同的 nonce 以及服务器多次接受相同的 nonce 是可以接受的。只要跟踪 jti 值并在 nonce 的生命周期内拒绝重复项，就没有额外的令牌重放风险。

11.2. DPoP 证明预生成

控制客户端的攻击者可以通过选择由所有权证明密钥签名的 DPoP 证明中的 iat 值，为特定端点预先生成任意遥远未来的 DPoP 证明。请注意，这类攻击者之一是客户端的合法用户。用户可以预先生成 DPoP 证明，将其从生成它们的拥有所有权证明密钥的机器中窃取出来，并将其复制到另一台不拥有该密钥的机器上。例如，银行员工可能会在银行计算机上预先生成 DPoP 证明，然后将其复制到另一台机器以备将来使用，从而绕过银行审计控制。当 DPoP 证明可以被预先生成和窃取时，在 DPoP 协议交互中实际证明的只是 DPoP 证明的所有权——而不是所有权证明密钥的所有权。

使用攻击者无法预测的服务器提供的 nonce 值可以防止这种攻击。通过在选择的时间提供新的 nonce 值，服务器可以限制 DPoP 证明的生命周期，防止预先生成的 DPoP 证明被使用。当使用服务器提供的 nonce 时，演示的是所有权证明密钥的所有权——而不仅仅是 DPoP 证明的所有权。

ath 声明将预先生成的 DPoP 证明的使用限制在访问令牌的生命周期内。不使用 nonce 机制的部署不应颁发长寿命的 DPoP 约束访问令牌，而应优先使用短寿命的访问令牌和刷新令牌。虽然攻击者可以预先生成 DPoP 证明以使用刷新令牌获取新的访问令牌，但他们实际上无法预先生成 DPoP 证明以使用新颁发的访问令牌。

11.3. DPoP Nonce 降级

当向客户端提供了 DPoP nonce 时，服务器不得接受任何没有 nonce 声明的 DPoP 证明。

11.4. 客户端上下文中的不可信代码

如果对手能够在客户端的执行上下文中运行代码，则不再保证 DPoP 的安全性。导致执行不可信代码的 Web 应用程序中的常见问题是 XSS 和远程代码包含攻击。

如果用于 DPoP 的私钥以无法导出的方式存储（例如，在硬件或软件安全模块中），则对手无法窃取密钥并用它来创建任意 DPoP 证明。但是，只要客户端在线，对手就可以创建新的 DPoP 证明，并在受害者设备上或在攻击者控制下的设备上使用这些证明（连同相应的令牌）发送将被服务器接受的任意请求。

为了在客户端离线时也能发送请求，对手可以尝试使用未来的时间戳预先计算 DPoP 证明，并将其与访问或刷新令牌一起窃取。

对手可能会进一步尝试将从令牌端点颁发的令牌与对手控制下的密钥对相关联。实现此目的的一种方法是修改现有代码，例如替换加密 API。另一种方法是在 iframe 中启动客户端和授权服务器之间的新授权许可。此许可必须是“静默的”，即不需要与用户交互。通过在客户端源中运行代码，对手可以访问生成的授权码，并使用它将自己的 DPoP 密钥与从令牌端点返回的令牌相关联。然后，即使客户端离线，对手也能够在自己的设备上使用生成的令牌。

因此，即使使用了 DPoP，保护客户端免受不可信代码执行的影响也极其重要。除了安全编码实践之外，内容安全策略 (CSP) [W3C.CSP] 可用作针对 XSS 的第二层防御。

11.5. 签名 JWT 交换

接受签名 DPoP 证明 JWT 的服务器必须验证 JWT 头部中的 typ 字段是否为 dpop+jwt，以确保对手不能使用为其他目的创建的 JWT。

11.6. 签名算法

实现者必须确保只有被认为是安全的非对称数字签名算法（如 ES256）才能用于签署 DPoP 证明。特别是，绝不允许使用 none 算法。

11.7. 请求完整性

DPoP 不保证请求的有效负载或头部的完整性。DPoP 证明仅包含 HTTP URI 和方法的声明，但不包含例如消息体或一般请求头。

这是一个有意为之的设计决策，旨在使 DPoP 易于使用，但如文中所述，这使得 DPoP 可能容易受到重放攻击，其中攻击者能够修改消息内容和头部。在许多设置中，TLS 提供的消息完整性和机密性足以为提供良好的保护级别。

注意：虽然覆盖请求其他部分的签名超出了本规范的范围，但可以将要签名的其他信息添加到 DPoP 证明中。

11.8. 访问令牌和公钥绑定

如第 6 节所述，访问令牌与 DPoP 公钥的绑定使用公钥的 JWK 表示形式的加密哈希。它依赖于哈希函数具有足够的第二原像抗性，使得找到或创建另一个产生相同哈希输出值的密钥在计算上是不可行的。之所以使用 SHA-256 哈希函数，是因为它在满足上述要求的同时广泛可用。

同样，DPoP 证明与访问令牌的绑定使用该访问令牌的哈希作为 DPoP 证明中 ath 声明的值（参见第 4.2 节）。这依赖于哈希值的唯一性足以可靠地识别访问令牌。SHA-256 的抗碰撞性满足该要求。

11.9. 授权码和公钥绑定

授权码与 DPoP 公钥的加密绑定在第 10 节中指定。此绑定可防止攻击者捕获授权码并使用客户端持有的密钥以外的所有权证明密钥创建 DPoP 证明并使用该 DPoP 证明兑换授权码的攻击。通过端到端确保只能使用客户端的 DPoP 密钥，这可以防止捕获的授权码被窃取并在颁发授权码的位置以外的位置使用。

例如，攻击者可以从记录包含授权码的 HTTP 消息的地方收集授权码。即使努力使授权码只能使用一次，在实践中，通常存在一个时间窗口，攻击者可以在此期间重放它们。例如，当授权服务器实现为可扩展的复制服务时，某些副本可能暂时还没有防止重放所需的信息。授权码的 DPoP 绑定解决了这些问题。

如果授权服务器不（或不能）严格执行授权码的一次性使用限制，并且攻击者可以访问授权码（如果使用了 PKCE，还可以访问 code_verifier），则攻击者可以创建伪造的令牌请求，将生成的令牌绑定到攻击者控制的密钥。例如，使用 XSS，攻击者可能会获得对授权码和 PKCE 参数的访问权限。使用 dpop_jkt 参数可防止此攻击。

授权码与 DPoP 公钥的绑定使用公钥的 JWK 指纹，就像访问令牌绑定一样。同样的 JWK 指纹注意事项也适用。

11.10. 哈希算法敏捷性

这里定义的 jkt 确认方法成员、ath JWT 声明和 dpop_jkt 授权请求参数都使用 SHA-256 哈希函数的输出作为其值。本规范使用单个哈希函数是有意的，旨在简化并避免因实现和部署参数化算法敏捷性方案时的常见错误而引起的潜在安全和互操作性问题。但是，如果未来情况发生变化，使得 SHA-256 无法满足本规范的要求，则不排除使用不同的哈希函数。如果出现这种需求，预计将制定一份简短的规范来更新本规范。使用适当哈希函数的输出作为值，该规范可能会定义新的确认方法成员、新的 JWT 声明和新的授权请求参数。这些项目将代替或与其各自的对应项一起用于本规范定义的更大协议的相同消息结构和流中。

11.11. 绑定到客户端身份

在 DPoP 与客户端身份验证一起使用的情况下，它仅通过在同一 TLS 隧道中同时发生来绑定到身份验证。由于 DPoP 证明没有直接以加密方式绑定到身份验证，因此身份验证或 DPoP 消息可能已被复制到隧道中。虽然在 DPoP 中包含 URI 可以部分减轻这种风险，但修改身份验证机制以在身份验证和 DPoP 之间提供加密绑定可以提供更好的保护。然而，通过修改身份验证机制或其他方式提供与身份验证的额外绑定超出了本规范的范围。