2. Objectives (目的)
2. Objectives (目的)
DPoP の主な目的は、トークンの発行時に公開鍵にバインドし、トークンの使用時にクライアントに、対応する秘密鍵の所有を証明させることで、漏洩または盗難されたアクセストークンが許可されていない、または不正な当事者によって使用されるのを防ぐことです。これにより、トークンの正当な送信者は秘密鍵を持つ当事者のみに制限され、送信者がトークンを使用する正当な権限を与えられているという保証をトークン受信サーバーに与えます。
DPoP を介して送信者制約されたアクセストークンは、トークンを所持している当事者なら誰でも使用できる典型的な Bearer (ベアラー) トークンとは対照的です。ベアラートークンの不注意な開示を防ぐための保護手段は一般的に講じられていますが、プロトコルまたはソフトウェアスタックの他の層における脆弱性や実装の問題により、予期しない漏洩経路が発生しています（例：Compression Ratio Info-leak Made Easy (CRIME) [CRIME]、Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) [BREACH]、Heartbleed [Heartbleed]、および Cloudflare パーサーのバグ [Cloudbleed]）。OAuth 実装自体も、多くの公表されたトークン盗難攻撃を経験しています（[GitHub.Tokens] はその注目すべき例の 1 つにすぎません）。DPoP は、偶発的なトークン漏洩の結果に対して多層防御として機能する一般的なメカニズムを提供します。ただし、DPoP はセキュアなトランスポートの代替ではなく、常に HTTPS と組み合わせて使用する必要があります。
典型的な OAuth プロトコルの相互作用の性質上、クライアントはアクセスする保護されたリソースにアクセストークンを開示する必要があります。[SECURITY-TOPICS] の攻撃者モデルでは、保護されたリソースが偽物、悪意的、または侵害されており、受信したトークンを他の保護されたリソースへの不正アクセスに使用する場合について説明しています。オーディエンス制限 (Audience-restricted) されたアクセストークン（例：JWT [RFC7519] の aud クレームを使用）は、このような悪用を防ぐことができます。しかし実際には、多くの展開において（[RFC8707] のような拡張があるにもかかわらず）これは負担が大きすぎることが証明されています。アクセストークンを送信者制約することは、異なるエンドポイントでのトークンのリプレイに対する、より堅牢で直接的な防止メカニズムであり、DPoP は実用的なアプリケーションレベルの手段です。
ブラウザベースの OAuth クライアントは、クロスサイトスクリプティング (XSS) の潜在的なリスクがあるため、トークンの保護に関する追加の考慮事項をもたらします。最も直接的な XSS ベースの攻撃は、攻撃者がトークンを盗み、正当なクライアントとは完全に独立してそれを使用することです。盗まれたアクセストークンは保護されたリソースへのアクセスに使用され、盗まれたリフレッシュトークンは新しいアクセストークンを取得するために使用されます。秘密鍵が（[W3C.WebCryptoAPI] で可能になるように）エクスポート不可能な場合、DPoP は盗まれたトークンだけでは役に立たないようにします。
XSS の脆弱性はまた、攻撃者がブラウザベースのクライアントアプリケーションのコンテキストでコードを実行し、クライアントを経由してトークンを悪用することを可能にします。この実行コンテキストは署名鍵へのアクセス権を持っています。したがって、トークンと組み合わせて使用される DPoP 証明を生成することができます。このアプリケーション層では、XSS を一般的に防ぐこと以外に、この脅威に対する実行可能な防御策はないと考えられます。したがって、これは DPoP の範囲外と見なされます。
ブラウザベースのクライアントアプリケーションのコンテキストで実行される悪意のある XSS コードは、将来のタイムスタンプ値を持つ DPoP 証明を作成し、トークンと一緒に外部に持ち出す可能性もあります。これらの盗まれたアーティファクトは、、後でクライアントアプリケーションとは独立して保護されたリソースにアクセスするために使用できます。これを防ぐために、サーバーはオプションで、攻撃者が予測できないサーバー選択値 (ノンス) をクライアントに証明に含めるよう要求することができます。オプションのノンスがない場合、事前計算された DPoP 証明の影響は、証明がアクセストークンにバインドされていることによって制限されます。まだ存在しないアクセストークンをカバーする証明を作成することは現実的にできないため、盗まれたリフレッシュトークンと事前計算された証明を使用して取得されたアクセストークンは、使用できません。
その他のセキュリティに関する考慮事項については、第 11 節で説明します。