WebAuthnパスキーのQRコードとBluetooth：ハイブリッドトランスポート

パスキーは、ユーザー認証における事実上の標準として、ますますパスワードに取って代わりつつあります。従来のパスワードとは異なり、パスキーはエコシステム（例：iCloudキーチェーン、Googleパスワードマネージャー、Windows Hello、または1PasswordやDashlaneのようなパスワードマネージャー）に紐づけられています。これらは記憶するように設計されておらず、デバイスとシームレスに統合し、すぐに使える優れたユーザーエクスペリエンスを提供するように作られています。

公共の端末や友人のノートパソコンなど、個人のコンピューターから離れているときに、パスキーで保護されたアカウントにログインする必要があると想像してみてください。このシナリオは非常に一般的であり、安全で便利な認証方法が必要ですが、パスキーの場合、この状況ではすぐに利用できないため、多くの人がどうすればよいかわかりません。このような状況で役立つパスキーの機能の1つが、QRコードとBluetooth技術を利用して複数のデバイス間でパスキーを使用する機能です。このプロセスは、WebAuthn仕様では正式にハイブリッドトランスポートとして知られています（仕様の以前のバージョンでは**caBLE（cloud-assisted Bluetooth Low Energy）**と呼ばれていました）。

プロセスは簡単です。パスキーが保存されており、写真を撮ることができるデバイス、つまりほとんどの場合はスマートフォンやタブレットが必要です。このデバイスは、その1回の認証インスタンスのためだけに新しいデバイスへのトンネルを開くことができます。これにより、パスキーの完全性が維持されるだけでなく、どこにいても、誰のデバイスを使ってログインしようとも、新しいデバイスでアカウントへのアクセスを許可できることが保証されます。

しかし、このパスキーのクロスプラットフォーム認証機能は、その有用性と技術的な実装の両方において、誤解や混乱に囲まれています。これは、最近地元のITセキュリティミートアップに参加したときに改めて気づいたことです。この記事を通じて、私たちはその複雑さを解き明かし、このクロスプラットフォームのパスキー認証（ハイブリッドトランスポート）フローを実装するための推奨事項を提供し、ユーザーに最高のログイン体験を提供できるようにすることを目指します。

パスキーは、従来のパスワードをより安全で便利な暗号学的な公開鍵と秘密鍵のペアに置き換えるユーザー認証の一形態です。この鍵ペアは各ユーザーに固有であり、複雑なパスワードを覚える手間なく本人確認に使用されます。

パスキーの利点は、パスワードの前身と比較して数多くあります。偽のウェブサイトと共有するように騙されることがないため、フィッシングのリスクを大幅に削減します。さらに、パスワードを解読するために使用される一般的な方法であるブルートフォース攻撃や辞書攻撃に対しても耐性があります。パスキーはまた、長いパスワードのリストを覚えたり管理したりする必要をなくし、よりユーザーフレンドリーです。

パスキーは、GoogleパスワードマネージャーやApple iCloudキーチェーン（MicrosoftはWindows Helloでまもなく追随予定）などのクラウドアカウントで同期されるか、1PasswordやDashlaneのような最新のパスキー対応パスワードマネージャーに保存されます。しかし、デフォルトではパスキーはエコシステムとそれぞれのクラウドアカウントの同期に紐づけられていることを知っておくことが重要です。オペレーティングシステムは秘密鍵をエクスポートするインターフェースを提供しておらず、ほとんどのデバイスでは、秘密鍵へのアクセスを防ぐための追加のセキュリティ対策を提供するハードウェアコンポーネントがあります。例えば、iOSデバイスのSecure EnclaveやWindowsデバイスのTrusted Platform Module (TPM)です。オペレーティングシステムのプロバイダーのみが、暗号化された方法でパスキーを他のデバイスに同期できます（最終的にはユーザーの生体認証、パスコード、またはPINで保護されます）。秘密鍵はパスコード/PINを使用してのみ復元および復号化でき、クラウドアカウントへのログイン試行が多すぎると破棄されます（例えば、Appleはクラウドバックエンドの特権的な位置からでもブルートフォース攻撃を防ぐためにレート制限を導入しており、Googleも同様です）。

この固有の設計は、パスキーが説明したように同期されていない場合、新しいデバイスでパスキーにアクセスすることが課題となる可能性があることを意味します。これこそが、QRコードとBluetoothの近接チェックによるパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）のためのハイブリッドトランスポート方式が存在する理由です。これにより、クラウドアカウント/パスワードマネージャーを介して同期する必要なく、デバイス間でパスキーの安全な橋渡しを提供し、パスキーがユーザーだけのものであり続けるという原則を維持します。

ハイブリッドトランスポートを使用したクロスプラットフォームパスキー認証は、アカウントが純粋にパスキーを介してアクセスされる場合のクロスデバイスの問題を克服するのに役立ちます。すべてのパスキーがクラウドアカウントやパスワードマネージャーで同期されるわけではないため、特に新しいデバイスに移行したり、共有デバイスでアクセスが必要になったりする場合に、デバイス間でパスキーにアクセスするための信頼できる方法が必要になります。

パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を容易にするためには、以下のハードウェア要件があります。

• WebAuthnサポート： デバイスはWebAuthnをサポートしている必要があります。これは、最新のパスキーデータ分析によると、すでに99%のデバイスで満たされています。
• QRコードスキャン用のカメラ： デバイスにはQRコードをスキャンできるカメラが必要です。ほとんどの現代のスマートフォンには、この機能を備えたカメラが搭載されています。さらに、カメラには組み込みのQRスキャン機能が必要です（ほとんどのデバイスが標準で備えています）。カメラがサポートしていない場合は、オンラインのQRスキャナーも良い選択肢です。それ以外の場合は、QRコードアプリをインストールするのも良いでしょう。
• Bluetooth機能： caBLE（Cloud-assisted Bluetooth Low Energy）は、デバイス間の近接ベースの安全な接続を確立するために使用されます。探すべきバージョンはBluetooth 4.0以上で、これによりWebAuthnのcaBLE拡張機能が有効になります。
• インターネット接続： 交換にはリアルタイムのデータ転送を必要とする検証ステップを実行するためのトンネルを開くことが含まれるため、両方のデバイスで安定したインターネット接続が必要です。

ソフトウェアの観点からは、以下の要件が存在します。

• WebAuthnサーバー設定： 当然ながら、公開鍵を管理するWebAuthnサーバーが必要です。これには、ユーザーのアカウントを複数の認証器にリンクできるようにし、認証セレモニーを開始するようにサーバーを設定することも含まれます。
• Web Bluetooth API： Bluetoothの近接チェックには、ブラウザからデバイスのBluetooth機能をトリガーするWeb Bluetooth APIにアクセスする必要があります。
• オペレーティングシステムの要件： 2025年3月時点での異なるオペレーティングシステムにおけるクロスデバイス認証のサポートについては、次の表を参照してください。認証器とは、パスキーを保持できるデバイス（このシナリオではスマートフォン）を意味します。クライアントとは、QRコードを作成し、ユーザーがログインしようとするデバイス（このシナリオではデスクトップ）を意味します。

出典: passkeys.dev

QRコードを介したパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を使用するプロセスは次のようになります。

パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）用のQRコードは、登録されたパスキーが存在しないデバイスでユーザーがサービスにアクセスしようとしたが、サービスがユーザーがパスキーを持っていることを知っている場合に生成されます。通常、認証インターフェース内に「QRコードをスキャン」ボタンまたは同様のコールトゥアクションが提供されます。

ユーザーの要求に応じて、デバイスはQRコードの生成を開始します。このQRコードは、一意で時間制限のあるセッション識別子をエンコードします。この識別子は、認証サーバーが認証プロセスの完了を待つ間、一時的に維持するセッションに結び付けられています。

ユーザーは、パスキーが利用可能なデバイスでこのQRコードをスキャンします。セキュリティ対策には以下が含まれます。

• 一度きりの使用： QRコード内のセッション識別子は一度の使用に限り有効であり、リプレイ攻撃を防ぎます。
• 暗号化： QRコード内のすべてのデータは暗号化されており、傍受された通信が不正な第三者によって解読されないことを保証します。

スキャンされたQRコードは、FIDOというスキームを持つ特定のURIを保持しています。例： FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

QRコードをスキャンすると、ユーザーの2番目のデバイス（例：スマートフォンやタブレット）がFIDO URIを解釈し、認証サーバーと通信して、ユーザーが新しいデバイス（例：友人のノートパソコン）を介して認証しようとしていることを示す信号を送信します。このアクションにより、サーバーはこの認証試行に固有の暗号学的チャレンジを生成するよう促されます。

チャレンジは、パスキーが保存されているユーザーの2番目のデバイス（例：スマートフォンやタブレット）に送り返されます。デバイスは、パスキーに関連付けられた秘密鍵を使用してデジタル署名を作成します。このとき、秘密鍵はデバイス（例：スマートフォンやタブレット）から決して離れません。署名されたチャレンジ（署名）は、安全な暗号化されたトンネルを介してインターネット経由でサーバーに送り返され、認証試行の完全性と発信元を検証します。

サーバーは、ユーザーのアカウントに既に関連付けられている対応する公開鍵を使用して署名を検証します。検証が成功すると、サーバーは認証を確認し、ユーザーが新しいデバイスでサービスにアクセスできるようになります。

考慮すべきさらに重要なプライバシーとセキュリティの側面：

• Bluetoothデータ交換なし、純粋なインターネット： このQRコードベースのパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）では、データ交換にBluetoothが関与しないことに注意することが重要です。このプロセスは、デバイスとサーバー間の暗号化されたデータの送信に完全にインターネット接続に依存しています。ただし、Bluetoothは2つのデバイスの近接チェックに使用されます。
• 秘密鍵はデバイスから離れない： このプロセス全体を通じて、ユーザーの秘密鍵はデバイス上に安全に保持されます。
• 機密データの漏洩なし： 認証プロセス中に機密性の高いパスキー情報や秘密鍵が転送されたり、漏洩したりすることはありません。
• 非対称暗号： チャレンジレスポンスメカニズムにより、送信されるのは再利用不可能な署名付きのチャレンジのみであり、不正アクセスのために悪用されることはありません。

これらの技術的およびセキュリティプロトコルを遵守することにより、パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）のためのQRコード方式は、ユーザーが新しいデバイスで自分の身元を認証するための便利な方法を提供しながら、高いセキュリティ基準を維持します。

QRコードのスキャンプロセスに加えて、Bluetooth（caBLE）を介した近接チェックもあります。クライアントと認証器が物理的に互いに近いことを確認することは、WebAuthnプロトコルの主要な利点の1つです。このプロセスの内部動作に関する詳細は、以下で説明します。

Bluetooth Low Energy (BLE) は、短距離データ交換用に設計された無線通信技術です。認証プロセス中にデバイスの物理的な近接性を確認する上で極めて重要な役割を果たします。

caBLE は、BLEを使用してデバイス間で認証情報を安全に転送することを容易にするプロトコルです。パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）にcaBLEを使用する場合、パスキーを保持するデバイスは、BLE信号を介して要求元デバイスの近接性を確認します。近接性が確認されると、認証プロセスは安全なローカル通信のためにBLEを活用して進行します。

この方法は通常、ユーザーの直接的な操作が少なくて済むため、ユーザーエクスペリエンスが向上します。物理的に近接しているデバイスは自動的に互いを検出します。セキュリティ面では、caBLEは大きな利点を提供します。それは、認証プロセスが2つのデバイスが互いに近くにある場合にのみ実行されることを保証し、リモートの攻撃者が認証プロセスを開始するのを防ぎます。

悪意のあるサイトにリダイレクトするQRコードを受け取ったと想像してみてください。このQRコードを通じて認証が実行されると、セッションやクッキーが乗っ取られるリスクがあります。BLEは、視覚的なスキャンに依存せず、デバイスの物理的な存在に依存することでこの問題を回避します。この近接チェックは、インターネットや視覚的な媒体を介して行われないため、中間者攻撃のリスクを最小限に抑えます。

他の方法とは異なり、caBLEは実際にはパスキーのような認証データを交換しません。代わりに、BLEをデバイスが物理的に近いことを確立するための確認チャネルとして使用します。このチェックは、BLEの近接性が要素の1つである多要素認証プロセスの一部として設計されており、他の要素が侵害された場合でも、物理的な近接性がなければアクセスが許可されないことを保証します。

caBLEプロトコルを統合することにより、開発者は認証プロセスの全体的なセキュリティを強化する、安全でユーザーフレンドリーなパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）方法を提供できます。近接チェックは、ユーザーにとってはシンプルでありながら、特定の種類の高度なサイバー攻撃から効果的に保護する追加の保護層を追加します。

このパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）方法には、以下の利点があります。

QRコードとBluetooth（ハイブリッドトランスポート）を介したクロスプラットフォームパスキー認証は、クロスプラットフォームのシナリオで全く可能性を提供しない場合と比較してUXを改善する方法です。しかし、このユーザーフローはほとんどのユーザーにとって全く新しいものであり、多くの非技術的なユーザーがこのフローに初めて遭遇したときに何が起こっているのかを理解することは期待できません。QRコードフローの導入に類似しているのは、例えばWhatsApp WebやDiscordのログインフローでQRコードが採用されている場合です（ただし、ここでの機能は異なります）。したがって、分析されたQRコード/Bluetooth（ハイブリッドトランスポート）を介したクロスプラットフォームパスキー認証プロセスは、クロスプラットフォームシナリオでのユーザーの労力を最小限に抑えますが、それでも全体的なフローはほとんどのユーザーにとって未知のものです。

パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）のセキュリティは、高度な暗号技術によって強化されています。認証のためにQRコードがスキャンされたり、Bluetooth接続が確立されたりすると、暗号学的チャレンジとレスポンスにより、意図したデバイスのみが認証プロセスを正常に完了できることが保証されます。

Bluetoothを介した近接チェックは、認証試行がセカンダリデバイスへの物理的なアクセスを持つ誰かによって行われていることを確認し、追加のセキュリティ層を追加します。

クロスプラットフォーム認証（ハイブリッドトランスポート）プロセス中、パスキーは中間デバイスやサーバーに一時的に保存されることはなく、転送プロセス中にパスキーが傍受されたり漏洩したりするリスクを防ぎます。認証はリアルタイムで行われ、パスキーはユーザーのプライマリデバイスに紐づけられたままであり、その完全性を維持します。

QRコードとBluetoothの認証方法は、本質的にフィッシングに対する保護を提供します。ユーザーは、認証プロセスがユーザーの信頼できるデバイスに固有の物理的なアクションを必要とするため、悪意のあるサイトにパスキーを提供するように騙される可能性が低くなります。

QRコードをスキャンしたり、Bluetooth経由で接続したりするプロセスは、通常、信頼できる環境で行われるため、ユーザーが誤って認証情報を漏洩させる可能性が減少します。

このパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）方法には、以下の欠点があります。

新しい技術を導入すると、特にユーザーが技術に詳しくない場合、ユーザーの混乱を招く可能性があります。QRコードとBluetooth（ハイブリッドトランスポート）を介したパスキーのクロスプラットフォーム認証は、従来の認証方法からの大きな転換であり、一部のユーザーは新しいプロセスを理解するのが難しいと感じる可能性があり、採用率が遅くなる可能性があります。しかし、ユーザーはいずれ慣れると予想されるため、最初は変化が難しいかもしれませんが、時間とともにスムーズになり、より受け入れられるようになるでしょう。

パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）の成功は、QRコードをスキャンできるカメラやBluetooth機能など、ユーザーのデバイスが必要な機能を備えているかどうかに大きく依存します。これらの機能を欠く古いデバイスを使用しているユーザーは、パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を利用できず、ハードウェアの制限に基づくデジタルデバイドを生み出します。

ユーザーの行動は予測不可能であり、QRコードのスキャンやBluetoothの有効化など、特定の行動をユーザーに依存することは、ユーザーエラーを引き起こす可能性があります。例えば、Bluetoothはペアリングの問題、検出の問題、安全な取引に対する無線技術への一般的なユーザーの不信感から、UXの課題と見なされることがあります。

開発者は、最新の認証方法をサポートするためにシステムを常に更新および維持するという課題に直面しています。既存のシステムにパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を統合するには、開発者が新しい標準を常に把握し、新しいAPIを採用し、後方互換性を確保する必要があり、これはリソース集約的で時間のかかる作業になる可能性があります。

iCloudキーチェーンのような同期されたクラウドアカウントやパスワードマネージャーを使用しない場合、新しいデバイスごと、またはその後のログイン要求ごとに新しいパスキーを作成する必要があります。これはユーザーエクスペリエンスに複雑さを加える可能性があり、ユーザーがプロセスに慣れていない場合や、直感的でない場合には不満を生む可能性があります。

パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）のような新しいセキュリティ方法を実装する際には、ユーザー教育が本質的に必要です。ユーザーがQRコードとBluetoothを安全に使用する方法を理解していることを確認するには、明確なコミュニケーションとおそらく広範なカスタマーサポートが必要です。

QRコードとBluetooth（ハイブリッドトランスポート）を介したパスキーのクロスプラットフォーム認証は、認証技術における大きな進歩を示していますが、これらの潜在的な欠点は、ユーザーフレンドリーな設計、堅牢なサポートシステム、そして従来の方法から革新的な方法への段階的で十分に伝えられた移行の必要性を浮き彫りにしています。どの技術的転換においても、革新の利点とその課題のバランスを取ることが、成功裏の実装と広範なユーザーの受け入れの鍵となります。

免責事項として、以下のテストではハードウェアセキュリティキー（例：YubiKey）を無視し、デバイスに組み込まれたプラットフォーム認証器（例：Face ID, Touch ID, Windows Hello）のみを使用します。ハードウェアセキュリティキー（例：YubiKey）の場合、トランスポートの値は例えばusbやnfcになります。

以下のデバイス/ブラウザの組み合わせとPasskeys Debuggerを使用して挙動をテストします。Androidはクロスプラットフォーム認証（ハイブリッドトランスポート）クライアントとして機能できないため、考慮されていません（上記の表「3.2 ソフトウェア要件」を参照）。

挙動をテストするために、各組み合わせで以下のプロパティを持つ新しいパスキーを作成します。

• userName: alex muller (このテストでは影響なし)
• authenticatorAttachment: platform (YubiKeyのようなハードウェアセキュリティキーを除外したいため)
• residentKey: preferred (このテストでは影響なし)
• userVerification: preferred (このテストでは影響なし)
• attestation: none (このテストでは影響なし)
• hints: empty (以下の説明を参照)
• usePRF: no (このテストでは影響なし)

パスキーの作成が成功した後、allowCredentials WebAuthnサーバープロパティへの入力を変更し、ログインリクエストを開始します。パスキーを作成したデバイス上でパスキーが削除された状況を模倣し、デバイス/ブラウザがQRコード/Bluetoothを介してパスキーを提供できる別のデバイスを探すようにします。そのため、クレデンシャルIDを変更し、値CHANGED-IDを割り当てて、一致が失敗するようにします。さらに、allowCredentials内のWebAuthnクレデンシャルのtransportsプロパティを変更し、各デバイス/ブラウザの組み合わせに以下の値を割り当てます。

1. transports: [internal, hybrid]: パスキーはプラットフォーム認証器（例：Face ID, Touch ID, Windows Hello）から、またはクロスプラットフォーム認証を介して使用できます。
2. transports: [internal]: パスキーはプラットフォーム認証器（例：Face ID, Touch ID, Windows Hello）からのみ使用できます。
3. transportsプロパティが設定されていない： 制限を与えないデフォルトの挙動。

WebAuthnテストサイトには、ユーザーエージェントヒントのための新しいWebAuthn Level 3機能も提供されています。この機能は、リライングパーティがログインリクエストを最もユーザーフレンドリーな方法で完了できるという特定の仮定を持っている場合に、ユーザーエクスペリエンスを向上させることができます。このテストでは、まだ展開されていないため、この機能は無視しました。詳細については、仕様を参照してください。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

何らかの理由で、モーダルの一部がインストールされている言語の1つであるドイツ語で表示されます。

予想通り、Windows Hello、QRコード、既知のデバイス、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

何らかの理由で、モーダルの一部がインストールされている言語の1つであるドイツ語で表示されます。

予想通り、Windows Hello、QRコード、既知のデバイス、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。

パスキーを作成する際に、以下のエラーが表示されました（それでもパスキーは作成されました）：

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

何らかの理由で、モーダルの一部がインストールされている言語の1つであるドイツ語で表示されます。

予想通り、Windows Hello、QRコード、既知のデバイス、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。さらに、既知のデバイスの1つを直接選択して、そこからパスキーを使用することもできます。

このモーダルは、WindowsのChrome 119のモーダルとはかなり異なります。

これは予想される挙動です。内部パスキーの使用のみを許可していますが、デバイス上で内部クレデンシャルを見つけることができないためです（ハイブリッドパスキーの使用は許可されていません）。このステップでパスキー認証は失敗し、実際のインプリメンテーションでは、フォールバック認証方法を提供する必要があります。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。さらに、既知のデバイスの1つを直接選択して、そこからパスキーを使用することもできます。

このモーダルは、WindowsのChrome 119のモーダルとはかなり異なります。

予想通り、Touch ID、QRコード、既知のデバイス、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

予想通り、Touch ID、QRコード、ハードウェアセキュリティキーを介したほとんどの形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

予想通り、Face ID、QRコード、ハードウェアセキュリティキーを介したほとんどの形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

非常に紛らわしいことに、内部クレデンシャルのみを許可しているにもかかわらず、ここでもQRコードが表示されます。この挙動の正当な理由は見つかりませんでした。

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

予想通り、Face ID、QRコード、ハードウェアセキュリティキーを介したほとんどの形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

以下では、Windows 10デバイスについて、Bluetoothが無効になっているか、一般的にWindows 10マシンで利用できない場合に挙動がどのようになるかをさらに深く分析することにしました。特に古いデスクトップデバイスでは、Bluetoothモジュールがないことが多いため、これは依然として非常に一般的なシナリオであり、QRコードとBluetoothを介したクロスプラットフォーム認証を不可能にします。

8.8.1.1 transports: [internal, hybrid]

予想通り、ローカルのパスキーは一致しないため、別のデバイスでパスキーを使用する（システムはこのユーザーにパスキーが存在することを知っているため - 最初のスクリーンショット）か、QRコードをスキャンする（2番目のスクリーンショット）ことが提案されます。

8.8.1.2 transports: [internal]

非常に紛らわしいことに、クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、Windows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められます。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.8.1.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

8.8.1.4 空のallowCredentials

予想通り、Windows Hello、QRコード、既知のデバイス、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。

8.8.2.1 transports: [internal, hybrid]

これはユーザーにとって非常に紛らわしいメッセージです。何をすべきか、どのように認証できるかが明示されていないためです。彼らが持つ唯一の選択肢は「キャンセル」をクリックすることであり、このシナリオは行き止まりになります。

8.8.2.2 transports: [internal]

この挙動はBluetoothが有効な場合と同じです。クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、ユーザーがWindows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められるのは非常に紛らわしいです。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.8.2.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、唯一の選択肢はハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することです。

8.8.2.4 空のallowCredentials

パスキー認証は、Windows Helloとハードウェアセキュリティキーを介してのみ可能です。

8.9.1.1 transports: [internal, hybrid]

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

8.9.1.2 transports: [internal]

非常に紛らわしいことに、クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、Windows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められます。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.9.1.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

8.9.1.4 空のallowCredentials

予想通り、Windows Hello、QRコード、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

8.9.2.1 transports: [internal, hybrid]

これはユーザーにとって非常に紛らわしいメッセージです。何をすべきか、どのように認証できるかが明示されていないためです。彼らが持つ唯一の選択肢は「キャンセル」をクリックすることであり、このシナリオは行き止まりになります。

8.9.2.2 transports: [internal]

この挙動はBluetoothが有効な場合と同じです。クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、ユーザーがWindows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められるのは非常に紛らわしいです。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.9.2.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、唯一の選択肢はハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することです。

8.9.2.4 空のallowCredentials

パスキー認証は、Windows Helloとハードウェアセキュリティキーを介してのみ可能です。

8.10.1.1 transports: [internal, hybrid]

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

8.10.1.2 transports: [internal]

非常に紛らわしいことに、クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、Windows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められます。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.10.1.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

8.10.1.4 空のallowCredentials

予想通り、Windows Hello、QRコード、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

8.10.2.1 transports: [internal, hybrid]

これはユーザーにとって非常に紛らわしいメッセージです。何をすべきか、どのように認証できるかが明示されていないためです。彼らが持つ唯一の選択肢は「キャンセル」をクリックすることであり、このシナリオは行き止まりになります。何らかの理由で、Windowsセキュリティモーダルの一部もドイツ語（このデバイスにインストールされている第2言語）で表示されます。

8.10.2.2 transports: [internal]

この挙動はBluetoothが有効な場合と同じです。クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、ユーザーがWindows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められるのは非常に紛らわしいです。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.10.2.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、唯一の選択肢はハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することです。

8.10.2.4 空のallowCredentials

パスキー認証は、Windows Helloとハードウェアセキュリティキーを介してのみ可能です。

8.11.1.1 transports: [internal, hybrid]

予想通り、ローカルのパスキーは一致しないため、QRコードをスキャンして別のデバイスでパスキーを使用することが提案されます（システムはこのユーザーにパスキーが存在することを知っているため）。

8.11.1.2 transports: [internal]

非常に紛らわしいことに、クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、Windows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められます。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.11.1.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、QRコードをスキャンするか、ハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することが提案されます。

8.11.1.4 空のallowCredentials

予想通り、Windows Hello、QRコード、ハードウェアセキュリティキーを介したすべての形式のパスキー認証が許可されます。何らかの理由で、既知のデバイスは表示されません。

8.11.2.1 transports: [internal, hybrid]

これはユーザーにとって非常に紛らわしいメッセージです。何をすべきか、どのように認証できるかが明示されていないためです。彼らが持つ唯一の選択肢は「キャンセル」をクリックすることであり、このシナリオは行き止まりになります。

8.11.2.2 transports: [internal]

この挙動はBluetoothが有効な場合と同じです。クレデンシャルIDを変更したにもかかわらず（したがって、allowCredentialsプロパティで指定されていないため、実際にはクレデンシャルを見つけるべきではありません）、ユーザーがWindows HelloのPINコード（またはデバイスに設定されていれば指紋/顔スキャン）の入力を求められるのは非常に紛らわしいです。しかし、Windows HelloのPINコードを送信すると、「NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client.」というエラーがスローされます。ユーザーの観点からは、これはかなり紛らわしい挙動ですが、ユーザーの同意なしにユーザーのパスキーに関する情報を提供する可能性があるため、理にかなっています。

8.11.2.3 transportsプロパティが設定されていない

ローカルのパスキーは一致しないため、唯一の選択肢はハードウェアセキュリティキー（例：YubiKey）/クロスプラットフォーム認証器/ローミング認証器を使用することです。

8.11.2.4 空のallowCredentials

パスキー認証は、Windows Helloとハードウェアセキュリティキーを介してのみ可能です。

• 純粋なWebAuthn APIの複雑さの一部を抽象化するライブラリやフレームワークを使用してください。
• 幅広いユーザーベースがパスキー実装の恩恵を受けられるように、最初からクロスプラットフォーム認証シナリオを考慮してください。設計の選択によっては、これらのシナリオで代替のログイン方法を提供することもできます。
• デバイスの制限によりパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）が不可能なシナリオのために、フォールバックメカニズムを開発してください。
• 最大の設計上の決定は、QRコード/Bluetooth（ハイブリッドトランスポート）を介したクロスプラットフォームパスキー認証を促進し、それをパスキー認証の主要な方法にするか、ヒントを使用して積極的に促進しないかを決定することです。後者の場合、常に内部に保存されているパスキーをすぐに使用しようとし、内部パスキーが見つからない場合にのみ、クロスプラットフォーム認証（ハイブリッドトランスポート）用のQRコードが表示されます。これは、WebAuthnサーバーオプションのexcludeCredentialsおよびallowCredentialsプロパティで定義する必要があります。WebAuthnサーバーのexcludeCredentialsプロパティでは、既に作成されたクレデンシャルのトランスポート情報を確認できます。allowCredentialsプロパティでは、ログインプロセス中の挙動を指定できます（上記のテストを参照）。
• さらに、クロスプラットフォームパスキー認証（ハイブリッドトランスポート）を完全に防ぐことはできません（transports: [internal]を使用した上記のテストを参照）。そのため、ユーザーがこの方法を見つけて質問してくることに備える必要があります。このクロスプラットフォーム認証（ハイブリッドトランスポート）は、特にユーザーがローカルでパスキーを削除し始めた場合に発生します。

• ユーザーにパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）プロセスを案内する包括的なガイドやチュートリアルを作成してください。
• ユーザーが初めてパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を体験する際に、アプリ内のツールチップや文脈に応じたヘルプセクションを使用してガイドしてください。
• ウェブサイトやアプリケーション内にFAQやトラブルシューティングセクションを提供してください。

• QRコードまたはBluetoothを介したパスキーログインに対して時間制限のあるセッションを実装し、アクセスが一時的で安全であることを保証してください。
• パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）が既存のセキュリティプロトコルを損なわないようにし、ユーザーデータの完全性を維持してください。
• プライバシーへの影響を考慮し、パスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）を介して付与された一時的なアクセスが、セキュリティのベストプラクティスに従ってログに記録され、監視されることを確認してください。

QRコード/Bluetooth（ハイブリッドトランスポート）を介したパスキーのクロスプラットフォーム認証は、セキュリティとUXのバランスを提供します。しかし、これはほとんどのユーザーにとって全く新しいプロセスであり、多くの混乱を招く可能性があるため、それを促進するかどうかは慎重に考える必要があります。

QRコード/Bluetoothを介したパスキーのクロスプラットフォーム認証（ハイブリッドトランスポート）のトピックに光を当て、設定方法や異なるデバイス/ブラウザの組み合わせでの挙動を説明できたことを願っています。ご質問があれば、私たちのパスキーコミュニティを通じてお気軽にお問い合わせいただくか、私たちのパスキーSubstackを購読してください。パスキーを広めることで、インターネットをより安全な場所にしましょう。