跳到主要内容

3. 概念

本规范引入的主要数据结构是 DPoP 证明 JWT (DPoP proof JWT)，它作为 HTTP 请求中的头部发送，正如下文详细描述的那样。客户端使用 DPoP 证明 JWT 来证明拥有对应于特定公钥的私钥。

粗略地说，DPoP 证明是对以下内容的签名：

  • 它所附加的 HTTP 请求的一些数据，

  • 一个时间戳，

  • 一个唯一标识符，

  • 一个可选的服务器提供的 Nonce，以及

  • 当请求中存在访问令牌时，关联访问令牌的哈希值。

+--------+                                          +---------------+
|        |--(A)-- Token Request ------------------->|               |
| Client |        (DPoP Proof)                      | Authorization |
|        |                                          |     Server    |
|        |<-(B)-- DPoP-Bound Access Token ----------|               |
|        |        (token_type=DPoP)                 +---------------+
|        |
|        |
|        |                                          +---------------+
|        |--(C)-- DPoP-Bound Access Token --------->|               |
|        |        (DPoP Proof)                      |    Resource   |
|        |                                          |     Server    |
|        |<-(D)-- Protected Resource ---------------|               |
|        |                                          +---------------+
+--------+

                      图 1: 基本 DPoP 流程

具有 DPoP 的 OAuth 流程的基本步骤（不包括可选的 Nonce）如图 1 所示。

A. 在令牌请求中，客户端向授权服务器发送授权许可（例如，授权码、刷新令牌等），以便获得访问令牌（以及可能的刷新令牌）。客户端在 HTTP 头部中将 DPoP 证明附加到请求中。

B. 授权服务器将访问令牌绑定（发送者约束）到客户端在 DPoP 证明中声明的公钥；也就是说，如果不证明拥有相应的私钥，就无法使用该访问令牌。如果将刷新令牌颁发给公共客户端，它也会绑定到 DPoP 证明的公钥。

C. 为了使用访问令牌，客户端必须再次通过向携带该请求的 DPoP 证明的请求添加头部来证明拥有私钥。资源服务器需要接收有关访问令牌绑定的公钥的信息。此信息可以直接编码到访问令牌中（对于 JWT 结构的访问令牌），也可以通过令牌内省端点（未显示）提供。资源服务器验证访问令牌绑定的公钥是否与 DPoP 证明的公钥匹配。它还验证 DPoP 证明中的访问令牌哈希值是否与请求中出示的访问令牌匹配。

D. 如果签名检查失败或 DPoP 证明中的数据错误（例如，目标 URI 与 DPoP 证明 JWT 中的 URI 声明不匹配），资源服务器将拒绝为该请求提供服务。当然，访问令牌本身在所有其他方面也必须是有效的。

这里提出的 DPoP 机制不是一种客户端身份验证方法。实际上，DPoP 的一个主要用例是针对不使用客户端身份验证的公共客户端（例如，单页应用程序和用户设备上的应用程序）。尽管如此，DPoP 旨在与 private_key_jwt 和所有其他客户端身份验证方法兼容。

DPoP 不直接确保消息完整性，而是依靠 TLS 层来实现该目的。详情请参见第 11 节。

最后于 更新