WebAuthnテストはFIDO2標準が従来のU2Fを置き換える中で出現し、クライアントデータ、アテステーションオブジェクト、暗号的課題を含む複雑な儀式状態機械を導入しました。コアの問題は認証機の異種性にあります。Windows Helloのようなプラットフォーム認証機は、レジデントキーの保存、輸送プロトコル（USB、NFC、BLE）およびUV要件について、YubiKeyのようなローミングハードウェアと根本的に異なります。また、ブラウザはクロスオリジンコンテキストに対して異なる権限ポリシーを強制します。体系的な手動方法論は、各デバイスをそのアテステーションフォーマット（packed、tpm、fido-u2f）、機能、および輸送の可用性によって分類する認証機分類マッピングを必要とします。テスターはChrome、Safari、Firefox、およびEdge全体で登録と認証の儀式を手動で実行し、ブラウザのDevToolsを介してCBORエンコードされたアテステーションオブジェクトを検査して、fmtおよびattStmt構造がFIDOメタデータサービス（MDS）に対して正しいことを確認する必要があります。クロスオリジンiframeコンテキストには特に注意が必要で、allow="publickey-credentials-create"およびallow="publickey-credentials-get"の権限が正しく強制されていること、そしてレジデントキーのフローが重複登録を防ぐためにexcludeCredentialsフィルタを適切に処理していることを検証する必要があります。
ある医療ポータルがCDNサブドメインから提供されるReactウィジェット内にWebAuthn登録を組み込み、医師が二要素認証にYubiKey 5 NFCを使用できるようにしたり、パスワードレスログインにmacOS Touch IDを使用できるようにしました。医師たちは、デスクトップのChromeで成功裏に登録した後、iOSのSafariがYubiKeyをNFC経由で認識しない断続的な失敗を報告し、ウィジェットが病院のEpic電子健康記録システムのクロスオリジンiframe内で読み込まれるときにTouch IDプロンプトが静かに失敗しました。私たちは、これらのハードウェア特有の統合失敗の根本原因を特定するために三つの異なるアプローチを考慮しました。
最初の解決策は、PuppeteerまたはSeleniumを使用して、WebDriver仮想認証機プロトコルを介して仮想認証機での自動テストを行うことです。この方法は、高速かつ完璧な再現性を提供し、サーバーサイドの課題応答処理とCBORパースロジックの回帰テストに最適です。しかし、これはYubiKeyの輸送ヒントがSafariのNFC実装と衝突するなど、特定のハードウェアの特異性を再現することには失敗し、バイオメトリックUVプロンプトや物理的タップインタラクションをシミュレーションすることはできません。
二つ目の解決策は、オフィスにあるデバイスを使用してユーザー体験について即座にフィードバックを提供するアドホック手動テストを提案しました。このアプローチは現実のブラウザ動作を捉えますが、一貫性のないカバレッジと再現性をもたらします。テスターは、AndroidデバイスがセキュリティキーのためにBLEペアリングを必要とすることを見逃すことが多く、iOSがNFCを好むため、偽のネガティブにつながります。さらに、構造化されたアテステーション検証が欠如しているため、本物のYubiKeyと無効なX.509証明書チェーンや不正なAAGUID値を返す侵害されたファームウェアクローンを区別することができませんでした。
三つ目の解決策は、物理デバイスを用いた構造化された認証機マトリックステストレジメを実施し、各認証機の機能（レジデントキーサポート、アテステーションフォーマット、輸送タイプ）をカタログ化し、ブラウザとOSの組み合わせ全体で儀式を手動で実行しました。Burp SuiteとブラウザのDevToolsを使用してトラフィックを傍受し、clientDataJSONおよびattestationObjectを検査しました。特に、allow属性を変更して登録フローをiframeに埋め込み、空のallowCredentials配列で認証を試みることによって、クロスオリジンシナリオをテストしました。
選択された解決策と結果
私たちは、WebAuthnの動作がハードウェア実装とブラウザセキュリティポリシーに根本的に結びついているため、構造化マトリックスアプローチを選択しました。この方法論により、Safariがクロスオリジンiframeに対して明示的なallow="publickey-credentials-get"属性を要求することが確認されましたが、Chromeは自動的にこれを推論しており、Epic統合内での静的な失敗の原因となっていました。さらに、YubiKey 5 NFCがtransports: ["nfc", "usb"]を返すが、iOS Safariは儀式中にnfcのみを列挙するため、サーバー側でallowCredentialsフィルタが厳密に強制された場合、資格情報が拒否されることが発覚しました。認証機が広告する任意の輸送を受け入れるようにサーバーの輸送検証を緩和し、手動テストチェックリストにiframeの権限確認を追加した後、病院の混合デバイスエコシステム全体でクロスデバイス認証が一貫して成功するようになりました。
ブラックボックステスト中に認証機が正当であり、侵害されたファームウェアやエミュレーターでないことを確保するために、アテステーションオブジェクトの暗号的整合性をどのように手動で確認しますか？
多くの候補者は、アテステーション検証が完全にサーバーサイドの問題であると仮定します。手動で検証するためには、ブラウザのPublicKeyCredential応答からattestationObjectを抽出し（base64urlデコードしてバイナリに変換）、CBORデバッガ（例えばcbor.me）を使用して解析し、fmtフィールドを検査します。packedアテステーションについては、X.509証明書チェーンをFIDO Alliance Metadata Service (MDS)に対して確認して、無効な認証機や自己アテステーションフラグをチェックします。tpmアテステーションについては、TPM証明書がEK（エンドースメントキー）を含んでいることを確認し、certInfo構造が期待されるハッシュアルゴリズムと一致していることを確認します。この手動検査により、自動化スクリプトが厳格なアテステーション検証をスキップした場合に見落とす可能性のある、不正な署名や不正確なAAGUID値を返す認証機をキャッチすることができます。
ユーザー存在（UP）とユーザー検証（UV）の正確な違いは何であり、これはプラットフォーム認証機とローミング認証機全体でレジデントキー（発見可能な資格情報）のテストにどのように影響しますか？
候補者の多くは、YubiKeyの単純なタッチ（UP）をPIN入力（UV）と混同します。手動テストでは、userVerification: "discouraged"を設定してもYubiKeyでの登録が許可されることを確認する必要があります（UPのみが可能）。しかし、residentKey: "required"を設定すると、ほとんどの認証機でUVが強制されます。テスターは、Windows Helloが常にUV（生体認証またはPIN）を行うことを見逃すことが多いですが、macOS Touch IDはフラグを尊重するものの、UVなしではレジデントキーの作成に失敗します。requiredおよびpreferredのレジデントキーの両方を使用して儀式を手動でテストし、認証機がallowCredentialsなしで認証中にcredentialIdを返すかどうかを観察し（それがレジデントであることを証明）、CBORパーサーを使用してauthenticatorDataフラグバイト（ビット0はUP、ビット2はUV）を確認し、認証機の動作がオプションに一致するかどうかを確認する必要があります。
物理的なセキュリティキーが1つしかない場合、重複登録を防ぐためにexcludeCredentials機能をどのようにテストし、認証機が既存の資格情報を正しく識別することを確認しますか？
これは、クライアントサイドの発見メカニズムの理解をテストします。資格情報を手動で登録し、rawIdをキャプチャしてから、同じuser.idと共にexcludeCredentialsを持つ新しい登録儀式を開始します。準拠する認証機は、InvalidStateErrorという名前のDOMExceptionを返す必要があります。ただし、候補者は、Windows Helloや一部のAndroidキーストアが、エラーの代わりに既存の資格情報を返す可能性があることを見逃すことがあり（これはWebAuthnレベル2仕様では有効です）、認証機が除外リストをサポートしない場合に当たります。両方の結果を確認する必要があります：サーバーがエラーを適切に処理し、返された資格情報が除外されたIDと一致し、サーバーサイドで拒否されることを確認することです。さらに、異なるuser.idを使用してテストし、認証機が異なるユーザーアカウントの資格情報を誤って除外しないことを確認する必要があります。これにより、重大なプライバシーの脆弱性を示します。