質問とシナリオ
面接官からIETF OAuthワーキンググループのドラフト「OAuth 2.0 Attestation-Based Client Authentication」が提示され、クライアントインスタンスが鍵にバインドされたアテステーション（構成証明）をどのように保持・送信するか、そしてそれをclient_secretおよびmTLSと比較するよう求められます。この質問では、プロトコルの成熟度、デバイス識別、およびデプロイメントにおける判断力が試されます。
面接官が見ているポイント
- OAuthクライアント、クライアントインスタンス、アテステーション発行者（Issuer）、および認可サーバー（Authorization Server）の分離。
- ドラフト段階の仕様を確定標準と呼ばずに、鍵バインディング、オーディエンス、有効期間、およびリプレイ対策を説明できること。
- 共有シークレット、mTLS、アテステーションを、信頼の起点（Trust Roots）、運用、障害モードの観点から比較できること。
回答前の明確化のための質問
ドラフトのバージョン、クライアントがモバイルアプリ、ハードウェアデバイス、サーバーのいずれであるか、誰がアテステーションを発行するか、認可サーバーがどの検証ルートを信頼するかを確認します。また、脅威モデル（鍵の複製、改ざんされたクライアント、トークンの移転、または通常のコンフィデンシャルクライアント認証）を明確にします。
30秒の回答フレームワーク
まず、これがIETF OAuth Internet-Draftであり、各フィールドは対象バージョンに依存することを述べます。中核となる考え方は、クライアントインスタンスが自身の鍵にバインドされたアテステーションを提示し、認可サーバーがOAuth認証を受け入れる前に証明書チェーン、オーディエンス、有効期間、および鍵の保有証明を検証することです。共有client_secretよりもインスタンスレベルの信頼を適切に表現できますが、発行者管理、ローテーション、失効、プライバシー対応の運用が追加されます。mTLSは信頼パスが異なり、既存のPKIを持つ環境に適しています。
ステップごとの詳細な回答
- 論理的なクライアント登録とクライアントインスタンスを分離します。インスタンスは鍵を生成または保持し、アテステーションはその鍵がインスタンスのプロパティとどのように関連しているかを示します。
- クライアントは、OAuth認証リクエストとともにアテステーションおよび鍵バインディング情報を送信します。サーバーは、署名、チェーン、オーディエンス、時間枠、nonceまたはその他のリプレイ制約、およびリクエストが秘密鍵で行われたことの証明を検証します。
- 検証後、認可サーバーは通常のOAuth認可またはトークン発行の前に、インスタンスの状態、クライアントID、ポリシー、およびリスクシグナルを統合します。アテステーション自体は認可ではありません。
- 期限切れのアテステーション、信頼されていない発行者、鍵の不一致、nonceの再利用、失効などを、機密情報を漏洩しないエラーで区別します。
- 信頼の起点、発行者のローテーション、失効リスト、デバイス交換、およびオフライン検証キャッシュを運用します。拒否の理由を説明可能にしておくため、バージョンと理由を記録します。
- ポリシーに必要なインスタンスプロパティのみを収集します。不要なリソースサーバーに永続的なデバイス識別子を開示することを避け、アテステーションの検証とリソースの認可を分離しておきます。
client_id = mobile-app
client_instance_key = K_instance
attestation = Sign_issuer(K_instance, audience=as.example, exp=t+300)
request_proof = Sign_K_instance(attestation, nonce, oauth_request_hash)高品質な回答例
まずドラフトのステータスとバージョンについて言及し、論理クライアントとインスタンスを分離して説明します。インスタンスは鍵を保持し、その鍵にバインドされた信頼できる発行者のアテステーションを提示します。認可サーバーは、署名チェーン、オーディエンス、有効期間、nonce、および秘密鍵の保有を検証し、その結果を認証の入力として使用します。アテステーションはスコープを付与するものではありません。client_secretと比較すると、共有シークレットの複製リスクが低減されます。mTLSと比較すると、アプリケーションインスタンスに適応しやすい反面、発行者、ローテーション、失効、プライバシーの運用が必要になります。本格導入前には、実験的なフィールドを恒久的なプロトコルとしてハードコードするのではなく、トラストルート、エラー、リプレイキャッシュ、交換フロー、およびドラフトバージョンの互換性を文書化します。
よくある間違い
- Internet-Draftを、発行済みのRFCや相互運用可能な標準と呼んでしまうこと。
- アテステーションによって自動的に認可やより上位のスコープが付与されると仮定すること。
- 発行者の署名のみを検証し、リクエスト鍵の保有証明、オーディエンス、またはnonceを検証しないこと。
- 失効、デバイス交換、クロックスキュー、およびオフラインキャッシュを無視すること。
- 最小化やテナント境界を考慮せずに、永続的なデバイス識別子でユーザーを追跡すること。
フォローアップの質問と回答
client_secretとの主な違いは何ですか？
client_secretは通常、複製可能な共有クレデンシャルであり、特定のインスタンスを識別することはできません。アテステーションはインスタンスの鍵を発行者のステートメントにバインドするため、トラストルートとライフサイクル管理のコストと引き換えに、インスタンスレベルの判断精度を向上させます。
mTLSとの主な違いは何ですか？
mTLSは相互TLSと証明書PKIを使用して接続層でクライアントを証明します。アテステーションはトランスポート層をまたいで機能させることができるOAuth認証の入力であり、発行者、検証、プライバシーモデルが異なります。
アテステーションのリプレイをどのように防止しますか？
リクエストのハッシュ、オーディエンス、短い有効期間、およびサーバーnonceをバインドし、使用済みnonceまたはアテステーション識別子をキャッシュし、バインドされた秘密鍵の保有を検証します。
変更されるドラフトをどのように段階的に展開しますか？
ドラフトのバージョン、アルゴリズム、検証機能を明示的な設定として扱います。互換性のある環境でカナリアリリースを行い、従来の認証へのフォールバックとメトリクスを維持した上で段階的に要件を厳格化します。未完成のフィールドを恒久的なプロトコルとして固定してはいけません。