認可コードフローには3つの役割が登場します。「ユーザー本人」「ユーザーがログインしたいアプリ（クライアント）」「Aurora IDのような認可サーバー」です。redirect_uriは、認可サーバーが発行した認可コードを「どこに届けるか」を決める、フローの中で最も重要な値の1つです。攻撃者がこのredirect_uriを操作できれば、本来アプリに届くはずの認可コードを自分のサーバーに届けさせることができます。

redirect_uriの検証さえ厳密であれば、この経路は安全に保たれます。次のセクションでは、その検証が緩いとどうなるかを見ていきます。

Aurora IDは、アプリを登録する際に「このアプリの認可コードは、このURLにだけ送ってよい」というredirect_uriを登録させます。認可リクエストが来たとき、Aurora IDはリクエストに含まれるredirect_uriが「登録された値と一致するか」を確認します。この確認の実装方法には複数のレベルがあります。

「https://todo-app.example」という文字列で始まっていれば安全、と考えるのは自然ですが、URLの世界ではそうとは限りません。ドメイン名は「ラベル」をピリオドで連結した構造になっており、攻撃者が自分の持つドメイン（例：attacker.example）の前に、被害者のドメイン名そのものをサブドメインのラベルとして自由に付け加えることができます。

次の実践チャレンジでは、この食い違いを実際に作り出し、認可コードを横取りする一連の流れを体験します。

Aurora IDに登録されているToDoループ（架空のToDoアプリ）のredirect_uriは、次の通りです。Aurora ID側の検証コードも見ることができます。よく見ると、検証は「文字列の先頭が一致するか」しか見ていません。

// Aurora ID側の検証コード（バグあり）
function naiveValidate(uri) {
  return uri.indexOf('https://todo-app.example') === 0;
}

• redirect_uriは完全一致で検証する：前方一致・部分一致・正規表現による緩い判定は使わない
• 複数のredirect_uriを許可する場合も、登録リストとの完全一致のみ許可する：ワイルドカードや「サブドメインなら何でも許可」のような設定は避ける
• stateパラメータでCSRF対策をする：認可リクエストごとに使い捨ての値を発行し、認可コードフロー自体への割り込みを防ぐ
• PKCE（Proof Key for Code Exchange）を使う：認可コードだけでなく、クライアントが生成した検証用の値も必要にすることで、コードを横取りされても交換できないようにする
• 認可コードは短命・使い捨てにする：発行から数十秒〜数分で失効させ、1回使われたコードは二度と使えないようにする

個々の処理は意図どおりに動いていても、検証の基準が「文字列としての見た目」のままだと、攻撃者にとっての入口が残ります。次のセクションでは今回の学びをまとめます。

第7話では、OAuth認可コードフローのredirect_uri検証が前方一致のように緩いと、認可コードそのものが攻撃者に渡ってしまう脆弱性クラスを体験しました。CTFの「フラグ探し」ではなく、実際の脆弱性レポートで繰り返し報告されている構造そのものです。