DPoP とトークンの漏えい
A 社の API は，SPA からのリクエストに DPoP（RFC 9449）を要求しており，アクセストークンは，SPA が生成した鍵ペアの公開鍵に結び付けて発行されている。API の前段の機器のログに Authorization ヘッダだけが記録されていたため，有効期限内のアクセストークンが攻撃者に漏えいした。SPA の秘密鍵は漏えいしていない。この場合に関する記述として，適切なものはどれか。
- アアクセストークンはベアラートークンと同じく所持者が利用できるので，攻撃者は Authorization ヘッダに設定すれば，有効期限内は API を利用できる。
- イAPI は，リクエストごとのプルーフの署名を検証し，トークンに結び付けられた公開鍵とプルーフの公開鍵が一致することを確かめるので，攻撃者はトークンを使えない。
- ウ攻撃者が自分で生成した鍵ペアの秘密鍵でプルーフに署名し，その公開鍵をプルーフに含めれば，署名の検証が成功するので API を利用できる。
- エAPI は TLS のクライアント証明書とトークンとの結び付きを確認するので，攻撃者は SPA のクライアント証明書を入手しない限り API を利用できない。
正解と解説を見る
正解 イ
この問題の基礎知識
- ベアラートークンは所持している者なら誰でも使えるトークンである。これに対し，送信者制約トークンは，トークンを特定の鍵などに結び付け，利用時にその鍵の所持を証明させる。
- DPoP では，クライアントが生成した鍵ペアの公開鍵にアクセストークンを結び付けて発行させ，リクエストごとに，秘密鍵で署名し公開鍵を含めた JWT（DPoP プルーフ）を送る。
- デジタル署名の検証の成功は，署名に使った秘密鍵と検証に使った公開鍵が対応していることを示すだけであり，その公開鍵が正当な相手のものかは別に確かめる必要がある。
- OAuth の相互 TLS（RFC 8705）はトークンを TLS のクライアント証明書に結び付ける方式であり，DPoP はアプリケーション層で送るプルーフによって鍵の所持を証明する方式である。
所持しているだけで誰でも使えるのはベアラートークン（RFC 6750）の性質である。DPoP のトークンを使うには，結び付けられた公開鍵に対応する秘密鍵で署名したプルーフをリクエストごとに付ける必要がある。
DPoP は，トークンを発行時に公開鍵に結び付け，利用時に対応する秘密鍵の所持をプルーフで証明させる。秘密鍵をもたない攻撃者は正当なプルーフを作れないので，漏えいしたアクセストークンだけでは API を利用できない。
署名自体は攻撃者の公開鍵で検証できても，API はトークンに結び付けられた公開鍵とプルーフの公開鍵の一致を確かめる。攻撃者の公開鍵は SPA の公開鍵と一致しないので，要求は拒否される。
クライアント証明書にトークンを結び付けるのは OAuth の相互 TLS（RFC 8705）の方式である。DPoP は TLS のクライアント認証を使わず，アプリケーション層で送るプルーフによって秘密鍵の所持を証明する。
照合の根拠（6 件）
- イ（正解）: トークンは発行時に公開鍵に結び付けられ，利用時に秘密鍵の所持の証明が求められるので，漏えいしたトークンだけでは使えない
The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token.
RFC 9449 · Section 2（新しいタブで開きます） - イ（正解）・ウ（誤り）: プルーフの署名はプルーフ内の公開鍵で検証されるので，攻撃者の鍵でも署名の検証自体は成功する
6. The JWT signature verifies with the public key contained in the jwk JOSE Header Parameter.
RFC 9449 · Section 4.3（新しいタブで開きます） - イ（正解）・ウ（誤り）: API はプルーフの公開鍵とトークンに結び付けられた公開鍵の一致を確かめるので，攻撃者の公開鍵では拒否される
Resource servers supporting DPoP MUST ensure that the public key from the DPoP proof matches the one bound to the access token.
RFC 9449 · Section 6（新しいタブで開きます） - ア（誤り）: 所持者が鍵の所持を示さずに使えるのはベアラートークンの性質
Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key).
RFC 6750 · Abstract（新しいタブで開きます） - エ（誤り）: トークンをクライアント証明書に結び付けるのは RFC 8705 の方式
OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.
RFC 8705 · Abstract（新しいタブで開きます） - エ（誤り）: DPoP はアプリケーション層の仕組みで，TLS のクライアント証明書を使わない
Demonstrating Proof of Possession (DPoP) is an application-level mechanism for sender-constraining OAuth [RFC6749] access and refresh tokens.
RFC 9449 · Section 1（新しいタブで開きます）
申し送りの「公開鍵の一致」: JWT のアクセストークンでは cnf.jkt に公開鍵の JWK SHA-256 サムプリントを入れて比較する（6.1）が，RFC 9449 自身が 4.3・6 章で「公開鍵が一致することを確かめる」と表現しており，イの記述は原文と矛盾しない。