OIDCリダイレクトURIがログイン機能ではなくセキュリティ境界である理由

OIDC認証が完了すると、IdPはユーザーをSaaSのリダイレクトURIへ戻します。一見するとログイン後の戻り先にすぎませんが、実際には認可コードが渡される重要なセキュリティ境界です。検証が緩いと、攻撃者が認証レスポンスを自分の管理するページへ誘導したり、別の顧客テナントのログインフローと混同させたりするおそれがあります。

近年のアイデンティティセキュリティでは、フィッシング、盗まれた認証情報、サプライチェーン攻撃に加え、設定ミスで生じる信頼境界の隙間も重視されています。OIDCを導入するだけでなく、「認証結果を正確にどこへ返すか」を運用で制御する必要があります。

リダイレクトURIは書留の受取住所

認可コードを重要書類が入った書留に例えてみましょう。受取住所をサンプルドメイン程度しか指定しなかったり、似た住所をすべて許可したりすると、別人に届く可能性があります。リダイレクトURIも、スキーム、ホスト、ポート、パスまで事前登録した値と厳密に照合することが基本です。

ワイルドカードと任意の戻り先を避ける

運用を簡単にするため広いワイルドカードを許可したり、リクエストごとに戻り先を自由指定できるようにしたりすると、攻撃対象が広がります。本番、ステージング、ローカル環境のURIは個別に登録し、不要になったURIは削除します。本番ではHTTPSを基本とし、開発用アドレスが本番アプリの設定に残っていないかも確認しましょう。

マルチテナントSaaSでは顧客境界も確認する

B2B SaaSでは、一つのサービスが複数顧客のログインを処理します。そのためURIの一致だけでなく、リクエストを開始したテナントとレスポンスを処理するテナントが同じかを確認する必要があります。stateでリクエストとレスポンスを結び、nonceでIDトークンの再利用を防ぎます。ブラウザやモバイルアプリなどのパブリッククライアントでは、PKCEの適用も検討してください。

OIDCとSAMLの違いは OIDCとSAMLの比較、SP側の連携フローは SSO SP連携ガイド で詳しく解説しています。

登録より変更管理が難しい

初期設定が安全でも、ドメイン移行、パス変更、顧客別カスタムドメインの追加によって例外が増えることがあります。変更申請には所有者、目的、対象環境、有効期限を残し、旧URIをいつ削除するかも決めておきます。失敗ログにはテナント、アプリ、検証結果を記録しつつ、認可コードやトークンなどの秘密情報は残してはいけません。

リリース前チェックリスト

• 登録URIと実際のコールバック先を完全一致で照合する • 本番、ステージング、ローカルのアプリ設定を分離する • state、nonce、必要に応じてPKCEの検証失敗を安全に拒否する • 未使用URIを定期的に削除し、変更履歴を保存する • 顧客ドメインは所有権を検証してから信頼する。詳しくは ドメイン検証ガイド をご覧ください

AxiPassで顧客ごとのSSO境界を一貫して運用

AxiPassは、SaaS企業がマルチテナント環境でOIDC・SAMLアプリ登録、SCIMプロビジョニング、MFA、SWA、監査ログをまとめて運用できるよう支援します。顧客ごとの設定と変更記録を分離することで、SSO展開のスピードを保ちながら、認証レスポンスの戻り先をより明確に管理できます。

顧客ごとのSSO連携を安全な初期設定から始めるなら、AxiPassを 無料で始める。