3. Concept (概念)

この仕様で導入される主なデータ構造は DPoP 証明 JWT (DPoP proof JWT) であり、以下で詳しく説明するように、HTTP リクエストのヘッダーとして送信されます。クライアントは DPoP 証明 JWT を使用して、ある公開鍵に対応する秘密鍵を所有していることを証明します。

大まかに言えば、DPoP 証明は以下の署名です。

それが添付されている HTTP リクエストのいくつかのデータ、
タイムスタンプ、
一意の識別子、
オプションのサーバー提供ノンス、および、
リクエストにアクセストークンが存在する場合は、関連するアクセストークンのハッシュ。

+------------+                                      +---------------+
|            |--(A)-- トークンリクエスト ---------->|               |
| クライアント|        (DPoP 証明)                  |   認可サーバー   |
|            |                                      |               |
|            |<-(B)-- DPoP バインドアクセストークン--|               |
|            |        (token_type=DPoP)             +---------------+
|            |
|            |
|            |                                      +---------------+
|            |--(C)-- DPoP バインドアクセストークン->|               |
|            |        (DPoP 証明)                   | リソースサーバー |
|            |                                      |               |
|            |<-(D)-- 保護されたリソース -----------|               |
|            |                                      +---------------+
+------------+

                      図 1: 基本的な DPoP フロー

DPoP を使用した OAuth フローの基本的な手順（オプションのノンスを除く）を図 1 に示します。

A. トークンリクエストにおいて、クライアントはアクセストークン（および場合によってはリフレッシュトークン）を取得するために、認可グラント（例：認可コード、リフレッシュトークンなど）を認可サーバーに送信します。クライアントは、HTTP ヘッダーで DPoP 証明をリクエストに添付します。

B. 認可サーバーは、アクセストークンを DPoP 証明内のクライアントの公開鍵にバインド（送信者制約）します。つまり、対応する秘密鍵の所有を証明しない限り、アクセストークンを使用することはできません。リフレッシュトークンがパブリッククライアントに発行される場合、それも DPoP 証明の公開鍵にバインドされます。

C. アクセストークンを使用するために、クライアントはリクエストの DPoP 証明を含むヘッダーをリクエストに再度追加することで、秘密鍵の所有を証明する必要があります。リソースサーバーは、アクセストークンがバインドされている公開鍵に関する情報を受け取る必要があります。この情報は、アクセストークンに直接エンコードされるか（JWT 構造のアクセストークンの場合）、またはトークンイントロスペクションエンドポイント（図示せず）を介して提供されます。リソースサーバーは、アクセストークンがバインドされている公開鍵が DPoP 証明の公開鍵と一致することを検証します。また、DPoP 証明内のアクセストークンハッシュがリクエストに提示されたアクセストークンと一致することも検証します。

D. 署名チェックが失敗した場合、または DPoP 証明内のデータが間違っている場合（例：ターゲット URI が DPoP 証明 JWT 内の URI クレームと一致しない場合）、リソースサーバーはリクエストへのサービス提供を拒否します。もちろん、アクセストークン自体も他のすべての点において有効でなければなりません。

ここで提案されている DPoP メカニズムは、クライアント認証方法ではありません。実際、DPoP の主なユースケースの 1 つは、クライアント認証を使用しないパブリッククライアント（例：シングルページアプリケーションやユーザーデバイス上のアプリケーション）です。それにもかかわらず、DPoP は private_key_jwt およびその他のすべてのクライアント認証方法と互換性があるように設計されています。

DPoP はメッセージの完全性を直接保証するものではなく、その目的のために TLS 層に依存しています。詳細については、第 11 節を参照してください。

3. Concept (概念)​

3. Concept (概念)