11. Security Considerations (セキュリティに関する考慮事項)

DPoP において、異なるエンドポイントでのトークンリプレイの防止（第 2 節を参照）は、[RFC6125] に従ったサーバーの認証と、DPoP 証明の特定の URI および HTTP メソッドへのバインディングによって達成されます。ただし、DPoP は、OAuth Mutual TLS [RFC8705] や OAuth Token Binding [TOKEN-BINDING] などの TLS ベースの方法とは、保護の性質が多少異なります（第 11.1 節と 11.7 節も参照）。TLS ベースのメカニズムは、TLS 層とアプリケーション層の間の緊密な統合を活用して、強力なメッセージの完全性、真正性、およびリプレイ保護を実現できます。

11.1. DPoP 証明のリプレイ

攻撃者が DPoP 証明 JWT を入手できた場合、攻撃者は同じエンドポイントでそのトークンをリプレイする可能性があります（HTTP エンドポイントとメソッドは、JWT 内のそれぞれのクレームを介して強制されます）。これを制限するために、サーバーは作成後、限られた時間（できれば数秒または数分程度の比較的短い期間）のみ DPoP 証明を受け入れなければなりません (MUST)。

ターゲット URI のコンテキストにおいて、サーバーは、それぞれの DPoP 証明 JWT が受け入れられる時間枠の間、各 DPoP 証明の jti 値を保存して、同じ DPoP 証明が複数回使用されるのを防ぐことができます。jti 値が以前に見られた同一 URI に対する HTTP リクエストは拒否されます。厳密に実施された場合、このような 1 回限りのチェックは DPoP 証明のリプレイに対する非常に強力な保護を提供しますが、単一のエンドポイントの背後にある複数のサーバーが共有状態を持たない場合など、実際には常に実行可能であるとは限りません。

メモリ枯渇攻撃を防ぐために、jti 値を追跡しているサーバーは、不必要に大きな jti 値を持つ DPoP 証明 JWT を拒否するか、そのハッシュのみを保存すべきです (SHOULD)。

注：クロックのずれに対応するために、サーバーは合理的に近い将来（数秒または数分のオーダー）の iat 時刻を持つ DPoP 証明を受け入れることができます (MAY)。サーバーとクライアント間のクロックのずれが大きくなる可能性があるため、サーバーは、クライアントが提供する iat 時刻をサーバーの時刻と比較するのではなく、サーバーの時刻を含むサーバー提供のノンス値を使用して DPoP 証明の寿命を制限することができます (MAY)。このように作成されたノンスは、任意に大きなクロックのずれがあっても同じ結果をもたらします。

サーバー提供のノンスは、DPoP 証明のリプレイが成功する可能性をさらに減らすための有効な手段です。暗号化ノンスとは異なり、クライアントが同じノンスを複数回使用することや、サーバーが同じノンスを複数回受け入れることは許容されます。jti 値が追跡され、ノンスの有効期間中は重複が拒否される限り、トークンリプレイの追加リスクはありません。

11.2. DPoP 証明の事前生成

クライアントを制御している攻撃者は、所有証明鍵によって署名される DPoP 証明の iat 値を選択することにより、特定のエンドポイントに対して将来の任意の時点の DPoP 証明を事前生成することができます。そのような攻撃者の 1 人は、クライアントの正当なユーザーであることに注意してください。ユーザーは、DPoP 証明を事前生成して、それらが生成された所有証明鍵を保有するマシンから持ち出し、鍵を保有していない別のマシンにコピーする可能性があります。たとえば、銀行員は銀行のコンピュータで DPoP 証明を事前生成し、それを別のマシンにコピーして将来使用することで、銀行の監査制御を回避するかもしれません。DPoP 証明を事前生成して持ち出すことができる場合、DPoP プロトコルの相互作用で実際に証明されているのは、DPoP 証明の所有であり、所有証明鍵の所有ではありません。

攻撃者が予測できないサーバー提供のノンス値を使用することで、この攻撃を防ぐことができます。サーバーが選択したタイミングで新しいノンス値を提供することで、サーバーは DPoP 証明の寿命を制限でき、事前生成された DPoP 証明が使用されるのを防ぐことができます。サーバー提供のノンスが使用される場合、証明されているのは所有証明鍵の所有であり、単なる DPoP 証明の所有ではありません。

ath クレームは、事前生成された DPoP 証明の使用をアクセストークンの寿命に制限します。ノンスメカニズムを利用しない展開では、長寿命の DPoP 制約付きアクセストークンを発行すべきではなく (SHOULD NOT)、代わりに短寿命のアクセストークンとリフレッシュトークンを使用することを推奨します。攻撃者はリフレッシュトークンを使用して新しいアクセストークンを取得するために DPoP 証明を事前生成することはできますが、新しく発行されたアクセストークンを使用するための DPoP 証明を現実的に事前生成することはできません。

11.3. DPoP ノンスのダウングレード

DPoP ノンスがクライアントに提供された場合、サーバーは nonce クレームのない DPoP 証明を受け入れてはなりません (MUST NOT)。

11.4. クライアントコンテキストでの信頼できないコード

攻撃者がクライアントの実行コンテキストでコードを実行できる場合、DPoP のセキュリティはもはや保証されません。信頼できないコードの実行につながる Web アプリケーションの一般的な問題は、XSS およびリモートコードインクルージョン攻撃です。

DPoP に使用される秘密鍵が、エクスポートできない方法で（例：ハードウェアまたはソフトウェアセキュリティモジュール内に）保存されている場合、攻撃者は鍵を持ち出して任意の DPoP 証明を作成するために使用することはできません。ただし、攻撃者は、クライアントがオンラインであり、これらの証明（およびそれぞれのトークン）を被害者のデバイスまたは攻撃者の制御下にあるデバイスで使用して任意のサーバーに受け入れられるリクエストを送信する限り、新しい DPoP 証明を作成できます。

クライアントがオフラインの場合でもリクエストを送信するために、攻撃者は将来のタイムスタンプを使用して DPoP 証明を事前計算し、これらをアクセスまたはリフレッシュトークンと一緒に持ち出そうとする可能性があります。

攻撃者はさらに、トークンエンドポイントから発行されたトークンを攻撃者の制御下にある鍵ペアに関連付けようとする可能性があります。これを達成する 1 つの方法は、既存のコードを変更することです（例：暗号化 API を置き換える）。別の方法は、iframe 内でクライアントと認可サーバーの間で新しい認可グラントを開始することです。このグラントは「サイレント」、つまりユーザーとの対話を必要としないものである必要があります。クライアントのオリジンでコードを実行すると、攻撃者は結果の認可コードにアクセスでき、それを使用して自分の DPoP 鍵をトークンエンドポイントから返されたトークンに関連付けることができます。その後、攻撃者はクライアントがオフラインであっても、自分のデバイスで結果のトークンを使用できます。

したがって、DPoP が使用されている場合でも、信頼できないコードの実行からクライアントを保護することは非常に重要です。安全なコーディング手法に加えて、Content Security Policy [W3C.CSP] は、XSS に対する防御の第 2 層として使用できます。

11.5. 署名付き JWT のスワッピング

署名付き DPoP 証明 JWT を受け入れるサーバーは、攻撃者が他の目的で作成された JWT を使用できないように、JWT のヘッダーの typ フィールドが dpop+jwt であることを検証しなければなりません (MUST)。

11.6. 署名アルゴリズム

実装者は、DPoP 証明の署名に、安全と見なされる非対称デジタル署名アルゴリズム（ES256 など）のみが使用できるようにしなければなりません (MUST)。特に、アルゴリズム none は許可してはなりません (MUST NOT)。

11.7. リクエストの完全性

DPoP は、リクエストのペイロードまたはヘッダーの完全性を保証しません。DPoP 証明には、HTTP URI とメソッドのクレームのみが含まれ、たとえばメッセージ本文や一般的なリクエストヘッダーは含まれません。

これは DPoP を使いやすく保つための意図的な設計決定ですが、説明したように、攻撃者がメッセージの内容とヘッダーを変更できる場合、DPoP はリプレイ攻撃の影響を受ける可能性があります。多くのセットアップでは、TLS によって提供されるメッセージの完全性と機密性は、十分なレベルの保護を提供するのに十分です。

注：リクエストの他の部分をカバーする署名はこの仕様の範囲外ですが、署名される追加情報は DPoP 証明に追加できます。

11.8. アクセストークンと公開鍵のバインディング

第 6 節で指定されているアクセストークンの DPoP 公開鍵へのバインディングは、公開鍵の JWK 表現の暗号化ハッシュを使用します。これは、ハッシュ関数が十分な第 2 原像耐性 (second-preimage resistance) を持ち、同じハッシュ出力値を生成する別の鍵を見つけたり作成したりすることが計算上実行不可能であることに依存しています。SHA-256 ハッシュ関数は、広く利用可能でありながら上記の要件を満たすため使用されました。

同様に、DPoP 証明のアクセストークンへのバインディングは、DPoP 証明の ath クレームの値としてそのアクセストークンのハッシュを使用します（第 4.2 節を参照）。これは、ハッシュ値がアクセストークンを確実に識別するのに十分な一意性を持っていることに依存しています。SHA-256 の衝突耐性は、その要件を満たしています。

11.9. 認可コードと公開鍵のバインディング

認可コードの DPoP 公開鍵への暗号化バインディングは、第 10 節で指定されています。このバインディングは、攻撃者が認可コードをキャプチャし、クライアントが保持しているものとは異なる所有証明鍵を使用して DPoP 証明を作成し、その DPoP 証明を使用して認可コードを引き換える攻撃を防ぎます。クライアントの DPoP 鍵のみが使用できることをエンドツーエンドで保証することで、キャプチャされた認可コードが持ち出され、認可コードが発行された場所以外で使用されるのを防ぎます。

認可コードは、たとえば、それらを含む HTTP メッセージがログに記録されている場所から攻撃者によって収集される可能性があります。認可コードを 1 回限りの使用にする努力が払われている場合でも、実際には、攻撃者がそれらをリプレイできる時間枠があることがよくあります。たとえば、認可サーバーがスケーラブルな複製サービスとして実装されている場合、一部のレプリカにはリプレイを防ぐために必要な情報が一時的にまだない場合があります。認可コードの DPoP バインディングは、これらの問題を解決します。

認可サーバーが認可コードの 1 回限りの使用制限を厳密に強制しない（またはできない）場合、および攻撃者が認可コード（および 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 間の暗号化バインディングを提供するように認証メカニズムを変更することで、より優れた保護を提供できます。ただし、認証メカニズムの変更やその他の手段による認証との追加のバインディングの提供は、この仕様の範囲外です。