リダイレクトURIとは

リダイレクトURIとは何か

リダイレクトURI（Redirect URI）は、OAuth/OIDCで利用者の認証が終わったあと、認可サーバーやIdPがブラウザを戻す先のURLです。アプリ側ではコールバックURLと呼ばれることもあります。

この値は単なる戻り先ではありません。認可コードやトークンを渡す入口になるため、事前登録したURIとリクエスト中のURIが一致しているかをIdPが確認します。ここが緩いと、別のサイトへ認証結果を送ってしまう余地が生まれます。

ログイン画面が表示されるのに最後だけ失敗する場合、まずリダイレクトURIを疑います。アプリ、IdP、ブラウザのどこでURLが変わったのかを切り分ける必要があります。

完全一致で見る理由

多くのIdPは、scheme、host、path、末尾スラッシュ、ポート番号、大小文字、クエリ文字列を含めてリダイレクトURIを照合します。https://example.com/callback と https://example.com/callback/ は別物として扱われることがあります。

本番、検証、ローカル開発を同じ登録に混ぜると、不要なURIが残りやすくなります。ワイルドカードや広すぎるドメイン許可は便利に見えますが、認証結果の戻り先を広げる設定でもあります。

• 登録済みURIと実際の認可リクエストを文字列で比較する。
• HTTPS、ポート、末尾スラッシュ、環境名を確認する。
• 使っていない検証環境や旧URLを削除する。

OAuth/OIDC障害で確認する証跡

リダイレクトURI不一致では、invalid_redirect_uri、redirect_uri_mismatch、AADSTS50011のようなエラーが出ることがあります。エラー文だけで直さず、認可リクエストに入っているredirect_uriの値と、IdPのアプリ登録を同じ時刻で確認します。

PKCEやstateを使っていても、リダイレクトURIの登録ミスは別問題として残ります。stateはリクエストの対応関係を守り、PKCEは認可コードの悪用を抑えます。戻り先そのものを正しく制限するのはリダイレクトURIです。

• ブラウザのアドレス、IdPログ、アプリログを保存する。
• client_id、redirect_uri、state、scopeを同じリクエストで見る。
• 成功時と失敗時のURL差分をチケットへ残す。

登録を増やす前に確認すること

エラーを消すだけなら、IdPにURIを追加すれば通る場合があります。しかし、そのURIが誰の管理下にあるか、今後も使うか、HTTPSで保護されるかを確認しなければ、古い戻り先が認証経路として残ります。

SSOの変更では、アプリ所有者、IdP管理者、DNS/Web担当の境界が分かれます。戻り先のURLがCDN、ロードバランサー、リバースプロキシで書き換わる場合もあります。

• URIの所有者と削除条件を決める。
• 本番/検証/ローカルを別アプリ登録に分ける。
• リバースプロキシのHost、X-Forwarded-Proto、パス変換を確認する。

変更記録への残し方

リダイレクトURIを変更したら、旧URI、新URI、対象アプリ、client_id、IdPテナント、反映時刻、ログイン確認結果、戻し条件を残します。URLだけをメモしても、あとでどのアプリ登録に効いた変更か追えません。

関連語としてOAuth、OIDC、クライアントID、PKCE、stateを並べると、認証フローのどの部分を直したのか説明しやすくなります。

• 登録画面の値と実リクエストの値を両方保存する。
• 不要URI削除の判断日と担当者を残す。
• ログイン成功だけでなくエラー時の再現条件も残す。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能