パスワードなしでも侵害される：OAuth同意フィッシング対策
正規のログイン画面とアプリ権限の同意を悪用するOAuth同意フィッシングの仕組み、マルチテナントSaaSの統制ポイントを解説します。
SSOとMFAを導入すればパスワード窃取のリスクは下がりますが、ユーザー自身が悪意あるアプリにデータアクセスを許可するOAuth同意フィッシング（Consent Phishing）まで自動的に防げるわけではありません。攻撃者はパスワードを求めず、正規IdPの同意画面へ誘導します。承認後に発行されたトークンでメール、プロフィール、ファイルなどへのアクセスを試みるため、ログイン成否だけを監視する運用では見逃しやすい攻撃です。
一般的なフィッシングとの違い
一般的なフィッシングは偽のログイン画面で認証情報を盗みます。一方、同意フィッシングは正規の認証後に表示されるアプリ権限要求を悪用します。URLやログイン画面が正しく見えても、要求元アプリ、発行者、リダイレクトURI、権限範囲（scope）が業務目的と一致するとは限りません。
MFAは「ログインした人物が誰か」を強化しますが、その人物がどのアプリへ何を委任してよいかまでは判断しません。そのため、認証ポリシーとアプリ同意ポリシーを別の統制として設計します。最小権限の考え方はOAuthスコープの最小権限設計で確認できます。
マルチテナントSaaSで確認する統制ポイント
顧客ごとにアプリ登録とリダイレクトURIを分離する
一つの共通OAuthクライアントに複数顧客の設定を混在させると、誤ったリダイレクトやテナント識別ミスの影響が広がります。顧客ごとに接続状態と承認主体を区別し、登録済みURIと完全に一致する要求だけを許可します。検証原則はOIDCリダイレクトURIのセキュリティも参照してください。
高リスク権限には管理者承認を求める
オフラインアクセス、全ファイルの読み取り、ディレクトリへの書き込みなど影響の大きい権限は、一般ユーザーが即時承認できないようにします。アプリ名だけでなく、検証済み発行者、要求scope、利用目的、データ保持範囲を管理者が確認します。
承認後のトークンライフサイクルも管理する
同意の撤回によって、すべてのセッションとトークンが即時失効するかは実装ごとに確認が必要です。未使用アプリ、長期間残るgrant、退職者が所有する接続を定期的に検出して撤回し、再承認や権限拡大を監査ログへ残します。
運用チェックリスト
- ユーザーが自由に承認できるアプリとscopeを制限します。
- 管理者承認ではアプリ所有者と業務目的の記録を必須にします。
- 新規同意、scope拡大、リダイレクトURI変更をアラート対象にします。
- 顧客ごとにOAuth接続とトークン失効を独立して検証します。
- インシデント時のアプリ遮断、grant撤回、セッション終了、影響ユーザー確認の順序を文書化します。
ログインと権限変更の記録を併せて保存すると、インシデントの影響範囲を再構成できます。必要な項目はSSO監査ログの保持ポリシーで確認してください。
AxiPassで顧客別の認証統制を一貫させる
AxiPassはSaaS企業が顧客ごとのOIDC・SAML SSO、SCIMによるアカウントライフサイクル、MFAをマルチテナント構成で管理できるよう支援します。標準連携が難しいアプリはSWAでアクセス経路を整理できます。OAuth同意ポリシーはアプリ側の統制と併用しつつ、認証主体・テナント・権限変更ログを一貫した基準で関連付けることで、不審な委任をより迅速に調査できます。