メインコンテンツまでスキップ

10. Authorization Code Binding to a DPoP Key (認可コードと DPoP 鍵のバインディング)

10. Authorization Code Binding to a DPoP Key (認可コードと DPoP 鍵のバインディング)​

クライアントに発行された認可コードを、そのクライアントの所有証明鍵にバインドすることで、認可フロー全体のエンドツーエンドのバインディングが可能になります。本仕様では、この目的のために dpop_jkt 認可リクエストパラメータを定義します。dpop_jkt 認可リクエストパラメータの値は、SHA-256 ハッシュ関数を使用した所有証明公開鍵の JWK サムプリント [RFC7638] であり、これは第 6.1 節で定義されている jkt 確認メソッドに使用される値と同じです。

トークンリクエストを受信すると、認可サーバーは DPoP 証明内の所有証明公開鍵の JWK サムプリントを計算し、それが認可リクエスト内の dpop_jkt パラメータ値と一致することを検証します。一致しない場合、認可サーバーはリクエストを拒否しなければなりません (MUST)。

dpop_jkt 認可リクエストパラメータを使用した認可リクエストの例を以下に示します。ここでは、[RFC8792] に従って "\" を使用して行を折り返しています。

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz\
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb\
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM\
    &code_challenge_method=S256\
    &dpop_jkt=NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs HTTP/1.1
Host: server.example.com

    図 25: dpop_jkt パラメータを使用した認可リクエスト

dpop_jkt 認可リクエストパラメータの使用は任意です (OPTIONAL)。dpop_jkt 認可リクエストパラメータは、認可コードインジェクションへの対策として [SECURITY-TOPICS] で推奨されている Proof Key for Code Exchange (PKCE) [RFC7636] と組み合わせて使用される場合があることにも注意してください。dpop_jkt 認可リクエストパラメータは、各認可リクエストに対して一意の DPoP 鍵が使用される場合にのみ、同様の保護を提供します。

10.1. DPoP と Pushed Authorization Requests​

Pushed Authorization Requests (PAR) [RFC9126] が DPoP と組み合わせて使用される場合、DPoP 鍵を PAR リクエストで伝達するには 2 つの方法があります。

  • 第 10 節で説明されているように、dpop_jkt パラメータを使用して、発行された認可コードを特定の鍵にバインドできます。この場合、dpop_jkt は、PAR リクエストの POST ボディ内の他の認可リクエストパラメータと一緒に含めなければなりません (MUST)。
  • あるいは、DPoP ヘッダーを PAR リクエストに追加することもできます。この場合、認可サーバーは、第 4.3 節で定義されているように、提供された DPoP 証明 JWT をチェックしなければなりません (MUST)。さらに、含まれている公開鍵のサムプリントが dpop_jkt を使用して提供されたかのように振る舞わなければなりません (MUST)。つまり、同じ鍵の DPoP 証明が提供されない限り、後続のトークンリクエストを拒否します。これにより、クライアントの実装が簡素化されます。クライアントは、リクエストの種類に関係なく、認可サーバーへのすべてのリクエストに DPoP ヘッダーを「盲目的に」添付できるからです。さらに、DPoP ヘッダーには秘密鍵の所有証明が含まれているため、より強力なバインディングが提供されます。

PAR と DPoP をサポートする認可サーバーは、両方のメカニズムをサポートしなければなりません (MUST)。両方のメカニズムが同時に使用される場合、dpop_jkt 内の JWK サムプリントが DPoP ヘッダー内の公開鍵と一致しない場合、認可サーバーはリクエストを拒否しなければなりません (MUST)。

両方のメカニズムを許可することで、dpop_jkt を使用するクライアントはフロントチャネルとプッシュされた認可リクエストを区別する必要がなくなり、同時に、認可サーバーのエンドポイントへのすべての呼び出しを保護するためのコードパスが 1 つしかないクライアントは、PAR エンドポイントへのリクエストとトークンエンドポイントへのリクエストを区別する必要がなくなります。

に最終更新