プロンプトとコンテキスト
リライングパーティ（RP）が、公開コンテンツ、従業員管理、高額取引向けに複数のアイデンティティプロバイダー（IdP）を統合しています。チームは、アサーション注入、保持者バインディング、プライバシー、リカバリを定義することなく、FALを「ログイン強度」として扱っています。NIST SP 800-63Cを使用してフェデレーション保証レベルを選択し、OIDCの検証と運用について説明してください。
FALは、フェデレーショントランザクションがアサーションをどのように保護し、バインドするかを記述します。これはIAL（身元確認）やAAL（認証器の強度）を置き換えるものではありません。NISTは、上位レベルが下位レベルの要件を包含すると述べています。さらにFAL3では、サブスクライバーがバインドされた認証器の証明をRPに直接提示することが求められます。
面接官がテストしていること
- 身元確認、ユーザー認証、アサーション配信の分離。
- FAL1、FAL2、FAL3の正しいセキュリティ特性と境界。
- イシュアー、オーディエンス、署名、nonce、有効期間、アサーション送信元の検証。
- 複数IdPの処理、注入、保持者バインディング、プライバシー、リカバリへの対応。
- レベル決定をポリシー、モニタリング、移行、例外処理へと落とし込むこと。
明確化のための質問
- リソースは公開コンテンツ、従業員用コンソール、または高額取引のどれですか？
- フェデレーションはOIDC、SAML、またはその他のプロトコルですか？また、アサーションの発行および検証は誰が行いますか？
- 設計において、アサーション注入、トークン転送、または盗難後のリプレイに耐える必要がありますか？ユーザーはバインドされた認証器を提示できますか？
- デバイス変更、リカバリ、オフライン利用、共有デバイスはどのように動作しますか？
- IdP間でのイシュアー、オーディエンス、JWKS、テナントマッピングはどのように維持されますか？
30秒の回答
ログイン画面からではなく、リソースのリスクに基づいてFALを選択します。FAL1は基本的なアサーション配信をカバーし、FAL2はアサーション注入などのフェデレーション攻撃に対する保護を追加し、FAL3はさらにサブスクライバーにバインドされた認証器の証明をRPに直接提示することを要求します。IAL、AAL、FALは個別に追跡します。OIDCのイシュアー、オーディエンス、署名、nonce、時刻を検証します。FAL3は高価値な操作のために確保し、リカバリ、プライバシー、キーローテーション、ロールアウトのコストを計画します。
詳細な回答
1. IAL、AAL、FALを分離する
IALは身元確認を記述し、AALはユーザーが認証器の制御をどのように証明するかを記述し、FALはRPに配信されるIdPアサーションの保護を記述します。ユーザーが強力なAALを持っていても、フェデレーショントランザクションのFALが不十分な場合があり得ます。FAL2は身元確認レベルを証明するものではありません。
リソースごとに、3つのレベルすべて、許可されたIdP、アサーションタイプ、リカバリパス、監査ログの保持期間を記録します。「OIDCを使用している」ことをFALに直接マッピングしてはなりません。
2. 3つのFALレベルを理解する
FAL1は、低リスクのサービス向けに基本的なフェデレーションアサーション配信を提供しますが、署名、イシュアー、オーディエンス、有効期間、セッションの検証は依然として必要です。
FAL2は、攻撃者が有効なアサーションを別のフェデレーショントランザクションに注入することに対する、より強力なアサーション配信保護を追加します。RPには、明示的なトランザクションコンテキスト、信頼できるIdP、および注入チェックが必要です。
FAL3はFAL2をベースとし、サブスクライバーが直接提示するバインドされた認証器の証明を必要とするため、アサーションの転送がより困難になります。デバイスバインディング、リカバリ、可用性、プライバシーのコストが増加するため、すべてのログインのデフォルトにすべきではありません。
3. OIDCアサーションを検証する
ID Tokenの署名、iss、aud、exp、iat、およびnonceを検証します。OpenID Connectでは、認証リクエストで送信された値とnonceを比較することが求められます。イシュアーURLのパスコンポーネントはそのアイデンティティの一部です。
JWKSは承認されたイシュアーからのみ取得し、kidが見つからない場合は制御された方法で更新します。ユーザー入力からディスカバリURLを構築したり、メールクレームをテナント間のアイデンティティキーとして扱ったりしてはなりません。
4. アサーション注入と転送に対抗する
認可リクエスト、イシュアー、クライアントID、リダイレクトURI、state、nonceをサーバー側で永続化します。コールバックは元のトランザクションと一致しなければなりません。不明なイシュアー、不正なオーディエンス、重複したstate、または不正なnonceがある場合、フローを停止します。
高リスクなリソースでは、トランザクション、リソース、セッションもバインドします。FAL2はコアとなるフェデレーションアサーション注入問題に対処しますが、PKCE、イシュアー識別、トークンオーディエンス、またはリソース認可を置き換えるものではありません。
5. FAL3のバインドされた認証器を設計する
FAL3では、サブスクライバーがバインドされた認証器の証明をRPに直接提示する必要があります。RPはバインディングを登録し、証明の鮮度とデバイスステータスをチェックし、紛失、交換、失効、リカバリを処理します。
リカバリは通常のIdPログインだけに依存することはできません。そうしないとバインディングがバイパスされる可能性があります。高リスクなリカバリには、独立した要素、手動レビュー、または有効化の遅延が必要となる場合があり、プロダクトチームとサポートチームはより高いコストと失敗率を受け入れる必要があります。
6. プライバシーと複数IdPに対応した運用
ビジネス上必要なクレームのみを要求し、アサーションの保持やログフィールドを制限します。異なるIdPのサブジェクトは、イシュアーおよびテナントスコープのマッピングなしに、単一のクロスドメインアイデンティティにマージすべきではありません。
署名エラー、イシュアーの競合、nonceのリプレイ、JWKS更新、アサーションサイズ、リカバリエントリ、FALごとの成功率を監視します。キーローテーション時にはオーバーラップ期間を設け、インフライトなセッションTTLの間、古いイシュアー構成が検証可能な状態を維持します。
7. 選択、ロールアウト、および例外の処理
公開コンテンツには通常、高いFALは必要ありません。従業員用コンソールにはFAL2を使用できます。送金、管理者キー、不可逆的なアクションにはFAL3の評価が適しています。例外については、リソース、期限、代替コントロール、オーナーを記録します。
完了率、リカバリ、サポートチケット、セキュリティイベントを比較しながら、テナントおよびリソースごとにロールアウトします。アサーション注入またはバインディングの失敗が発生した場合はロールアウトを停止します。可用性のために高リスクな操作をFAL1へサイレントに引き下げてはなりません。
模範回答
私はIAL、AAL、FALを個別に評価します。低リスクなコンテンツにはFAL1を使用し、従業員およびマルチIdPフローにはより強力な注入防御を備えたFAL2を使用し、管理者キーや不可逆的な転送などの高価値な操作にはFAL3を検討し、バインドされた認証器とリカバリを事前に設計します。
すべてのOIDCコールバックでイシュアー、オーディエンス、署名、時刻、nonceを検証し、イシュアー、クライアント、state、リダイレクトURI、トランザクションをバインドします。JWKSは承認されたイシュアーからのみ取得し、オーバーラップを伴ってローテーションします。テナントごとにロールアウトし、注入、リプレイ、リカバリ、完了率を監視し、すべての例外に期限と代替コントロールを設定します。検証障害の発生時、高リスクフローはフェイルクローズ（安全側に倒して拒否）とします。
よくある間違い
- FALをログイン強度として扱い、IALとAALを無視すること。
- OIDCが自動的にFAL2またはFAL3を意味すると想定すること。
- イシュアー、オーディエンス、nonce、有効期間、トランザクションコンテキストを確認せず、署名のみをチェックすること。
- ユーザーから提供されたイシュアーまたは
kidによって、任意のディスカバリやキー取得がトリガーされることを許可すること。 - バインドされた認証器とリカバリの設計なしに、FAL3が単一の設定であると主張すること。
- 異なるIdPからのメールクレームを1つのアイデンティティにマージすること。
- 完了率のために、高リスクな操作をFAL1へサイレントにダウングレードすること。
フォローアップの質問と回答
FAL2はAAL2とどのように異なりますか？
AAL2は認証器の強度を記述し、FAL2はフェデレーションアサーション配信の保護を記述します。これらは独立しており、個別に記録および構成されるべきです。
FAL3はどのような場合にコストに見合いますか？
管理者キーや不可逆的なトランザクションなど、アサーション転送のリスクが重要であり、ユーザーがバインドされた認証器の証明を提示できる高価値なアクションの場合です。コストとリカバリ能力を総合的に評価する必要があります。
なぜnonceが依然として重要なのですか？
nonceはID Tokenをこの認証リクエストにバインドし、古いレスポンスのリプレイを減らします。これはイシュアー、オーディエンス、署名、またはFALポリシーを置き換えるものではありません。
IdPのJWKSが利用できない場合はどうなりますか？
制御された短期キャッシュを使用します。高リスクなアサーションが検証できない場合は、フェイルクローズしてアラートを発報します。未知のキーを受け入れたり、検証をスキップしたりしてはなりません。
デバイスの交換はどのように処理しますか？
FAL3では、新しいバインディングと承認されたリカバリパスが必要です。通常のIdPログインはリカバリ要素の1つになり得ますが、古いデバイスバインディングを暗黙的に引き継ぐことはできません。
プロダクトチームにFALの選択をどのように説明しますか？
リソースのリスク、アサーション転送の影響、ユーザー層、リカバリコスト、コンプライアンス要件を説明します。レベル名だけを挙げるのではなく、期限、メトリクス、代替コントロールを記録します。