リフレッシュトークンの再提示
認可サーバは，パブリッククライアントの SPA に対し，RFC 9700 に従ってリフレッシュトークンのローテーションを行っている。次のトークンエンドポイントのログ（抜粋）の 10:15:03 の要求に対する処理として，適切なものはどれか。
10:00:12 grant=refresh_token rt=RT-a1 result=ok new_rt=RT-a2 src=198.51.100.7
10:14:40 grant=refresh_token rt=RT-a2 result=ok new_rt=RT-a3 src=203.0.113.50
10:15:03 grant=refresh_token rt=RT-a2 src=198.51.100.7- ア使用済みの RT-a2 が再び提示されたので漏えいが発生したとみなし，要求を拒否するとともに，有効な RT-a3 も無効化する。
- イ送信元 IP アドレスが 10:00:12 の要求と一致するので，10:14:40 の要求を攻撃者によるものとみなし，RT-a3 を無効化して新しいトークンを発行する。
- ウRT-a2 は使用済みなので要求だけを拒否し，その後に発行された RT-a3 は，正規のクライアントの利用を妨げないよう有効なまま残す。
- エ通信の再送による同一トークンの再提示とみなし，10:14:40 の要求に対して発行した RT-a3 を，もう一度応答として返す。
正解と解説を見る
正解 ア
この問題の基礎知識
- OAuth 2.0 のアクセストークンは API の呼出しに使う有効期間の短いトークンであり，リフレッシュトークンはアクセストークンの期限切れ時に新しいアクセストークンを取得するためのトークンである。
- パブリッククライアントは SPA やネイティブアプリのようにクライアントシークレットを安全に保持できないクライアントであり，クライアント認証によってリフレッシュトークンの不正利用を防げない。
- リフレッシュトークンのローテーションでは，使用のたびに新しいリフレッシュトークンを発行して古いものを無効化する。無効化済みのトークンが提示されたことは，トークンの漏えいの兆候となる。
ア使用済みの RT-a2 が再び提示されたので漏えいが発生したとみなし，要求を拒否するとともに，有効な RT-a3 も無効化する。正解
ローテーションでは，使用済みのトークンが再提示されたことで，攻撃者と正規のクライアントの双方が同じトークンを持っていたと判断できる。どちらが攻撃者かは区別できないので，有効な RT-a3 を失効させて攻撃を止め，正規のクライアントには再認可を求める。
イ送信元 IP アドレスが 10:00:12 の要求と一致するので，10:14:40 の要求を攻撃者によるものとみなし，RT-a3 を無効化して新しいトークンを発行する。
RFC 9700 は，認可サーバはどちらが無効なトークンを提示したかを判別できないとしている。送信元 IP アドレスは利用者の移動などで変わるので，正規の要求と判断して新しいトークンを発行する根拠にはならない。
ウRT-a2 は使用済みなので要求だけを拒否し，その後に発行された RT-a3 は，正規のクライアントの利用を妨げないよう有効なまま残す。
10:14:40 の要求が攻撃者によるものであれば，攻撃者は有効な RT-a3 を持ち続け，アクセストークンを取得し続けられる。再提示を検知しても有効なトークンを失効させなければ，攻撃は止まらない。
エ通信の再送による同一トークンの再提示とみなし，10:14:40 の要求に対して発行した RT-a3 を，もう一度応答として返す。
再送とみなして RT-a3 を返すと，10:15:03 の要求元が攻撃者だった場合に有効なトークンを渡してしまう。20 秒以上の間隔があり送信元も異なる要求を再送とする根拠はなく，使用済みトークンの提示は漏えいの兆候として扱う。
検証用の出典出典照合済み
RFC 9700 Best Current Practice for OAuth 2.0 Security ／ RFC 6749 The OAuth 2.0 Authorization Framework照合の根拠（3 件）
- ア（正解）・エ（誤り）: 無効化済みの RT-a2 の再提示は漏えいを示すものとして扱う
If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.
RFC 9700 · Section 4.14.2（新しいタブで開きます） - ア（正解）: どちらが提示したかは判別できないので，有効な RT-a3 を失効させ，正規のクライアントには再認可を求める。イ（誤り）: どちらが攻撃者かを判別して新しいトークンを発行する扱いではない。ウ（誤り）: 有効なトークンを失効させなければ攻撃は止まらない
The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.
RFC 9700 · Section 4.14.2（新しいタブで開きます） - 前提: パブリッククライアントでは送信者制約かローテーションでリフレッシュトークンの再利用を検知しなければならない
Authorization servers MUST utilize one of these methods to detect refresh token replay by malicious actors for public clients:
RFC 9700 · Section 4.14.2（新しいタブで開きます）
エ（誤り）は，RT-a3 をもう一度返すと 10:15:03 の要求元が攻撃者だった場合に有効なトークンを渡すことになり，同節の「使用済みトークンの提示は漏えいの通知」とする扱いに反するので排除される。