WebAuthnトランスポート：internalおよびhybridトランスポート

エンタープライズPasskeyホワイトペーパー. パスキープログラム向けの実践ガイド、展開パターン、KPI。

ホワイトペーパーを入手

注：WebAuthnの仕様では、空のトランスポートシーケンスは、トランスポート情報が利用できないか、プライバシーのために保留されていることを意味します。ブラウザでは、多くの場合、すべてのトランスポートが利用可能であるとみなして処理されます。

プラットフォーム間でパスキーを実装する際、開発者は重要な決断を迫られます。

• 最適なクロスデバイス認証のエクスペリエンスを確保するためには、WebAuthnトランスポート、特にinternalおよびhybridトランスポートをどのように処理すべきでしょうか？

その答えは、オーセンティケーターがリライングパーティとどのように通信するかを決定する技術的な詳細である、WebAuthnトランスポートを理解することにあります。理論上、トランスポートは単純に思えますが、その実装はWebブラウザ、ネイティブのiOSアプリケーション、ネイティブのAndroidアプリケーション間で、特にinternalおよびhybridトランスポートの処理において大きく異なります。

この記事では、さまざまなプラットフォーム全体でWebAuthnトランスポートがどのように機能するかを検証し、internalおよびhybridトランスポートを処理するための2つの異なるアプローチ（それぞれ独自のトレードオフがある）を紹介します。

この記事の内容：

1. WebAuthnトランスポート：Web、iOS、Androidにわたるinternal、hybrid、およびプラットフォームオーセンティケーター
2. 2つのアプローチ：仕様準拠 vs 最適化されたinternalおよびhybridトランスポートの処理
3. クロスデバイス認証の実装に関するベストプラクティスと推奨事項

WebAuthnトランスポートは、オーセンティケーターとクライアントデバイス間の通信方法を定義します。 WebAuthn Level 3仕様では、6つのトランスポートタイプが定義されています。

usb: YubiKeyや他のFIDO2セキュリティトークンのような、USBポート経由で接続するハードウェアセキュリティキーで使用されます。

nfc: 近距離無線通信（Near Field Communication）を通じてオーセンティケーターとの通信を可能にし、ユーザーがセキュリティキーやNFC対応デバイスをかざして認証できるようにします。

ble: Bluetooth Low Energyによる認証を促進し、外部のオーセンティケーターとの無線通信を可能にします。

smart-card: スマートカードリーダーで使用され、スマートカードによる認証を可能にします。

hybrid: クロスデバイス認証を可能にします。これは通常、ユーザーがスマートフォンを使用してデスクトップブラウザで認証を行う（またはその逆）など、QRコードをスキャンしてデバイス間で認証を行う場合に使用されます。このトランスポートは、デスクトップデバイスとモバイルデバイスの両方でQRコードのプロンプトをトリガーする可能性がありますが、コンテキストによっては常に望ましいとは限りません。注：hybridはWebAuthn Level 3で追加されました。

internal: iPhoneのiCloud キーチェーン（Face IDまたはTouch IDで検証）、PCのWindows Hello、AndroidデバイスのGoogle パスワードマネージャーのように、デバイス自体に埋め込まれているオーセンティケーターです。これらはプラットフォームオーセンティケーターです。

パスキーが作成されると、オーセンティケーターは自身がサポートしているトランスポートを通知します。この情報はリライングパーティ（バックエンド）に送信され、資格情報とともに保存する必要があります。認証中、リライングパーティはallowCredentialsリスト内でこれらのトランスポートをクライアントに送り返し、ブラウザやプラットフォームがユーザーに提示する認証方法を決定するのに役立てます。

トランスポートの処理はプラットフォーム間で大きく異なり、これが開発者が直面する互換性の課題を生み出しています。

ブラウザはオーセンティケーターからトランスポート情報を受け取り、認証フロー中にそれを尊重します。Chrome、Safari、Edgeでパスキーを作成すると、ブラウザの資格情報マネージャーは、基盤となるオーセンティケーターに基づいて異なるトランスポートデータを提供します。

プラットフォームオーセンティケーター: Windows Helloは、デバイスにバインドされた性質を反映して、["internal"]のみを提供します。しかし、ChromeがGoogle パスワードマネージャーをオーセンティケーターとして使用する場合、Google パスワードマネージャーがAndroidスマートフォン経由でのクロスデバイス認証をサポートしているため、["internal", "hybrid"]を提供します。

ハードウェアセキュリティキー: 実際の機能に基づいて["usb", "nfc"]などの特定のトランスポートを提供します。

クラウド同期型の資格情報マネージャー: SafariのiCloud キーチェーンやChromeのGoogle パスワードマネージャーは通常、ローカルおよびクロスデバイス認証の両方のフローをサポートするために["internal", "hybrid"]を提供します。

この情報はWebコンテキストで確実にやり取りされますが、特定のトランスポートはブラウザが資格情報ストレージとして選択するオーセンティケーターに依存します。

ドキュメント: W3C WebAuthn Specification

AndroidのCredential Manager APIはWebブラウザと同様に機能します。ネイティブのAndroidアプリでパスキーを作成すると、Credential ManagerはWebの動作を反映したトランスポート情報を提供します。プラットフォームオーセンティケーターは自らの機能を正確に報告し、システムはトランスポートデータを一貫して処理します。Android開発者は、特別な処理を必要とせずにこの情報に依存することができます。

ドキュメント: Android Credential Manager

iOSはより複雑な状況を呈します。AppleのAuthenticationServicesフレームワークは、オーセンティケーターの種類によってトランスポートの処理が異なります。

プラットフォームオーセンティケーター (iCloud キーチェーン、Face IDまたはTouch IDで検証): パスキー作成時に、しばしば空のトランスポート配列を返します。これは、トランスポート情報が利用できないか、プライバシーのために保留されていることを示します。WebAuthn仕様によれば、トランスポート情報が不明な場合やプライバシーを保護するために、ユーザーエージェントは空のシーケンスを返すことがあります。リライングパーティは、トランスポートを保証ではなくヒントとして扱うべきです。

セキュリティキー: iOSデバイスで使用される場合、予想されるパターンに従ってトランスポート情報（例：["usb"]、["nfc"]）を提供します。

ドキュメント: Apple AuthenticationServices

Webおよびネイティブアプリケーションからの現実の本番データは、頻度順に以下のトランスポートパターンを明らかにしています。これらの分布は実装の詳細やクライアントの人口統計（モバイルとデスクトップの使用比率、ネイティブアプリの可用性）の影響を受けますが、典型的なトランスポートの使用状況に関する貴重な洞察を提供します。

主な洞察:

プラットフォームオーセンティケーターが多数を占める: パスキーの大部分はinternalトランスポートを使用し、多くの場合クロスデバイス認証をサポートするためにhybridと組み合わされます。これは、コンシューマーがプラットフォームオーセンティケーター（iCloud キーチェーン、Google パスワードマネージャー）を重視していることを反映しています。

空の配列が一般的: iOSのネイティブアプリケーションは、プラットフォームオーセンティケーターに対して空のトランスポート配列を頻繁に返し、本番の資格情報の大部分を占めています。セクション2.2.3で述べたように、これらは包括的なトランスポートのサポートではなく、トランスポート情報が利用できないことを示しています。

セキュリティキーはまれ: ハードウェアセキュリティキー（usb、nfc）は本番のパスキーのごく一部にすぎず、コンシューマーアプリケーションではなく主にエンタープライズや高セキュリティのシナリオでの使用を示しています。

順序のバリエーションが存在する: 配列内のトランスポートの順序（["internal", "hybrid"] と ["hybrid", "internal"]）はプラットフォームとオーセンティケーターの実装によって異なりますが、機能的な違いはありません。どちらも同じトランスポート方法のサポートを示しています。

レガシーな用語: cableトランスポート識別子は古い実装で時折見られ、hybridと同義です（caBLE = cloud-assisted Bluetooth Low Energy、hybridトランスポートの元々の名前）。

この分布は、現実のパスキー実装の圧倒的多数を占めるinternalおよびhybridトランスポートを正しく処理することの重要性を補強しています。

トランスポートの可用性は、オーセンティケーターが何を報告するかを示すものであり、結果として得られるフローが完了するかどうかを示すものではありません。Corbado Passkey Benchmark 2026クロスデバイス認証完了の分析によると、2026年第1四半期のhybridトランスポートの完了率は、全体としてWindows Webで60〜78%、macOS Webで66〜86%と測定され、同一デバイスプロンプトの79〜98% (Win) / 83〜98% (macOS) と、識別子ファーストフローの52〜67% (Win) / 59〜76% (macOS) に分かれます。ルーティングロジックではhybridを最もコストの高いトランスポートとして扱い、資格情報を保持しているデバイスにユーザーを留まらせるフローを優先してください。

同じオーセンティケーターでも、プラットフォーム、バージョン、および実装コンテキストに基づいて異なるトランスポートパターンを報告することがよくあります。このバリエーションは正常であり、予想されるものです。

iCloud キーチェーンは3つのパターンを示します。

• ["internal", "hybrid"] - 最も一般的。通常はWebブラウザから。
• [] (空の配列) - 非常に一般的。iOSネイティブアプリから。
• ["hybrid", "internal"] - あまり一般的ではない。順序のバリエーション。
• 単独の ["internal"] または ["hybrid"] - まれなエッジケース。

Google パスワードマネージャーは最もバリエーションに富んでいます。

• ["hybrid", "internal"] - 最も一般的なパターン。
• ["internal", "hybrid"] - 一般的な代替順序。
• ["internal", "cable"] - レガシーな実装（cable = hybridの古い用語）。
• [] (空の配列) - 特定のネイティブコンテキストから。
• 単一のトランスポートはまれ。

Windows Helloは最も一貫しています。

• ["internal"] - 支配的なパターン（設計上デバイスにバインドされているため）。

1Password、Bitwarden、Dashlane、LastPassなどのパスワードマネージャーは、すべて同様のバリエーションパターンを示します。

• ["internal", "hybrid"] と ["hybrid", "internal"] の両方の順序。
• ネイティブアプリのコンテキストからの空の配列 []。
• 時折 ["internal"] のみ。

Samsung Pass (Androidエコシステム) は主に以下を使用します。

• ["hybrid", "internal"] と ["internal", "hybrid"] - どちらの順序も一般的。

プラットフォームの違い: 同じオーセンティケーターでも、Webとネイティブ、iOSとAndroid、あるいはWindowsとmacOSでは動作が異なります。

バージョンの進化: トランスポートの報告は時間の経過とともに進化してきました。古いバージョンではhybridの代わりにcableを使用したり、異なる組み合わせを報告したりする場合があります。

実装の選択: internalを優先するオーセンティケーターもあれば、hybridを優先するものもあります。順序は機能的な影響を与えませんが、実装によって異なります。

コンテキストの感度: 特にiOSのネイティブアプリでは、Webコンテキストでは完全なトランスポートを報告するオーセンティケーターからでも、空の配列を受け取ることがよくあります。

重要なポイント: あるオーセンティケーターに対してトランスポート配列が一貫していると想定しないでください。正確な配列の一致ではなく、特定のトランスポートの存在に焦点を当て、すべてのバリエーションを適切に処理するように実装を設計してください。

開発者は、仕様に厳密に従うか、ユーザーエクスペリエンスのためにinternalおよびhybridトランスポートを最適化するかという選択を迫られます。それぞれのアプローチにメリットとデメリットがあります。

このアプローチはWebAuthn仕様と一致しています。資格情報の登録中にオーセンティケーターが提供したトランスポートをそのまま使用し、認証中もそのまま送信します。

実装: パスキーが作成されたら、オーセンティケーターの応答からtransports配列を保存します。認証中は、allowCredentialsリストにこれらの正確なトランスポートを含めます。

{
    "allowCredentials": [
        {
            "id": "credential-id-base64",
            "type": "public-key",
            "transports": ["internal", "hybrid"]
        }
    ]
}

メリット:

• 仕様への準拠: WebAuthn標準に正確に従うことで、将来のプラットフォームのアップデートとの互換性を確保します。
• セキュリティキーの信頼性: 正確なトランスポート情報を常に提供するハードウェアセキュリティキー（YubiKeyなど）で完全に機能します。
• 無効なオプションの防止: 実際にサポートされていない認証方法（たとえば、Windows Helloの資格情報に対するQRコードのトリガー）を提供するのを回避します。

デメリット:

• iOSの空の配列の動作: iOS上のプラットフォームオーセンティケーターは空のトランスポートを返しますが、これはトランスポート情報が利用できないことを示しています。表示する認証オプションを決定する際に、プラットフォームはこれを異なる解釈をする可能性があります。
• 不要なオプションの表示: セキュリティキーが想定されていないコンシューマーアプリケーションで、セキュリティキーのオプション（USB、NFC）を提示してしまう可能性があります。
• 一貫性のないユーザーエクスペリエンス: 同じアカウントでも、プラットフォームによって提供される認証オプションが異なります。

最適: 標準への準拠を優先するアプリケーション、多様なオーセンティケータータイプを持つエンタープライズ環境。

このアプローチは、特定の最適化の目標に基づいて、internalおよびhybridトランスポートを選択的に変更することで、ユーザーエクスペリエンスを優先します。一律のルールの代わりに、以下の一般的な最適化シナリオを検討してください。

問題: iOSプラットフォームオーセンティケーターは空のトランスポート配列を返します。空のままにしたり、バックエンドによって埋められたりすると、ユーザーはプラットフォームのオプションの横にセキュリティキーのプロンプト（USB、NFC）を目にする可能性があり、コンシューマーアプリケーションで混乱を招きます。

解決策: iOSプラットフォームオーセンティケーターの場合、トランスポートを明示的に["hybrid", "internal"]に設定します。これにより、プラットフォーム認証とクロスデバイスフローのみが提供され、セキュリティキーのオプションが隠されます。

// iOSプラットフォームオーセンティケーターの資格情報を保存する場合
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

結果: iOSで作成されたパスキーに対して、セキュリティキーのプロンプトがないクリーンな認証UI。

問題: モバイルデバイスで認証を行う際、クロスデバイス認証用のQRコードを表示するとUXが低下します。ユーザーはすでにパスキーが利用可能なモバイルデバイス上にいるためです。

解決策: ユーザーがモバイルデバイスから認証を行っている場合は、hybridトランスポートを削除し、["internal"]のみを残します。

// 認証用にallowCredentialsを構築する場合
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

結果: モバイルユーザーには、不要なQRコードのプロンプトが表示されず、直接の認証オプションのみが表示されます。

⚠️ 注意: トランスポートの操作がプラットフォーム間で常に一貫した結果をもたらすとは限りません。広範なテストによれば、ブラウザとOSの組み合わせによってトランスポートの処理は異なります。

• トランスポートからhybridが除外されていても、QRコードを表示するプラットフォームもあります。
• hybridが含まれていても、QRコードを隠すプラットフォームもあります。
• 動作は、Windows、macOS、iOS全体のChrome、Edge、Safari、Firefox間で大きく異なります。

行き止まりのリスク: 過度に制限的なトランスポートのフィルタリングは、ユーザーがまったくログインできない認証の行き止まりを生み出す可能性があります。たとえば、hybridを削除すると、ユーザーが借りたデバイスから認証する必要がある正当なクロスデバイス認証シナリオが妨げられる可能性があります。常に代替の認証方法を提供し、トランスポートの最適化を展開する前にターゲットプラットフォーム全体で十分にテストを行ってください。

これらは最適化のヒントです: WebAuthnは、トランスポートの操作を超えて、認証UXを最適化するための他のメカニズム（ヒントなど）を提供しています。

トランスポートの動作は予測不可能: hybridトランスポート経由のクロスデバイス認証（CDA）は、ブラウザとOSの組み合わせ全体で一貫性のない動作を示します。実際のテストでは、トランスポートの値が特定のUIの動作を保証しないことが実証されています。プラットフォームはトランスポートを異なって解釈・処理し、予期しない結果を招くことがあります。

プラットフォーム固有の複雑さ: トランスポートを明示的に制御する場合、プラットフォームの違いを考慮する必要があります。

• iOS: プラットフォームオーセンティケーターに対して空の配列を送信するため、入力を必要とします。
• Windows Hello: ["internal"]のみのままでなければなりません。hybridを追加すると、不要なQRコードがトリガーされます。
• WebおよびAndroid: 一般的に正確なトランスポート情報を提供します。
• CDAのバリエーション: トランスポート配列内のhybridの有無に関わらず、QRコードのプロンプトが表示されたり消えたりすることがあります。

エンドツーエンドの理解が必要: トランスポートを明示的に制御することは、フロー全体に対して責任を持つことを意味します。すべてのターゲットプラットフォームにわたって各トランスポートの組み合わせがどのように動作するかを理解し、十分にテストする必要があります。トランスポートの操作により、ユーザーにとって有効な認証パスが存在しない認証の行き止まりが生じる可能性があります。

メリット:

• カスタマイズされたUX: 特定のコンテキストでユーザーに表示される認証オプションを正確に制御します。
• iOSの空の配列の問題を解決: iOSが何も提供しない場合にトランスポートを明示的に定義します。
• コンテキストを認識した最適化: デバイスのタイプに基づいて認証UIを適応させます。

デメリット:

• 予測不可能な動作: トランスポートの操作は一貫したUIの動作を保証するものではありません。広範なテストによれば、プラットフォームはトランスポートを異なる方法で解釈し、トランスポートの値に関係なくオプションを表示したり非表示にしたりすることがあります。
• 認証の行き止まりのリスク: 過度に制限的なトランスポートのフィルタリングは、特にクロスデバイスシナリオにおいて、ユーザーの認証を完全に妨げる可能性があります。
• 仕様からの逸脱: 仕様の推奨から離れるため、将来のプラットフォーム変更で問題を引き起こす可能性があります。
• メンテナンスの負担: プラットフォームが進化するにつれて、継続的なプラットフォーム固有のロジックと更新が必要になります。
• 複雑さ: iOSの空の配列、Windows Helloの制約、その他のプラットフォームの特異性を手動で処理する必要があります。
• テストのオーバーヘッド: すべてのプラットフォームの組み合わせにわたって、すべての最適化ルールの検証が必要です。

最適: 特定のUX要件を持つコンシューマーアプリケーション、プラットフォーム固有のロジックを維持するリソースを持つチーム、厳格な仕様の準拠よりも合理化された認証フローを優先するシナリオ。

WebAuthnトランスポートの処理は単独で存在するのではなく、パスキー実装の全体的な戦略の一部です。本番環境の展開では、2つの一般的なアプローチが現れており、それぞれがinternalおよびhybridトランスポートの使用に対して異なる影響を与えます。

このアプローチは柔軟性と標準への準拠を優先し、ユーザーが互換性のある任意のオーセンティケーターで認証できるようにします。

実装の特徴:

• 認証UI: パスキーボタンが既存のログインオプション（ユーザー名/パスワード）と並んで表示されます。
• allowCredentials: 空の配列 [] に設定され、任意の資格情報が一致できるようになります。
• オーセンティケーターの種類: セキュリティキー、クロスデバイス認証（QRコード）、プラットフォームオーセンティケーターのすべてがサポートされます。
• ネイティブアプリの要件: セキュリティキーを含むすべての認証方法をサポートする必要があります。
• preferImmediatelyAvailableCredentials: 定義上、セキュリティキーやQRコードログインを除外するため、使用できません。
• トランスポート処理: セキュリティキートランスポート（usb、nfc、ble）を含むすべてのトランスポートタイプに対応する必要があります。

トランスポートの意味合い:

allowCredentialsが空の場合、認証中のトランスポートの重要性は低くなります。プラットフォームは利用可能なすべてのオプションを表示します。しかしこれは、ユーザーがセキュリティキーのプロンプト、QRコード、およびプラットフォームのオプションを同時に目にする可能性があることを意味し、コンシューマーアプリケーションでは決定麻痺を引き起こす可能性があります。

最適: エンタープライズ環境、セキュリティキーのサポートを必要とする多様なユーザーベースを持つアプリケーション、最大限の認証の柔軟性を優先するシナリオ。

このアプローチは、パスキーの作成をプラットフォームオーセンティケーターに限定し、識別子ファーストのフローを使用することで、コンシューマーのUXを最適化します。

実装の特徴:

• パスキーの作成: ユーザー主導のプロンプト（ログイン後のプロンプト、自動作成フロー）はauthenticatorAttachment: "platform"を使用し、すぐに利用可能なオーセンティケーターに焦点を当てます。
• セキュリティキーのサポート: authenticatorAttachmentの制限なしでWebのアカウント設定から利用可能であり、パワーユーザーがセキュリティキーを含む任意のオーセンティケーターを選択できるようにします。
• 認証フロー: 識別子ファースト。ユーザーは認証前にメールアドレスまたはユーザー名を入力します。
• allowCredentials: 識別子がわかった後、ユーザー固有の資格情報（空ではない）が入力されます。
• オーセンティケーターの種類: プラットフォームオーセンティケーターとクロスデバイス認証が優先されます。セキュリティキーはサポートされますが、主要なフローでは推奨されません。
• ネイティブアプリの最適化: セキュリティキーやQRコードのプロンプトなしに、サイレントで即時の認証を行うためにpreferImmediatelyAvailableCredentialsを使用します。
• クロスデバイス認証: Webで利用可能です。preferImmediatelyAvailableCredentialsを使用する場合、ネイティブアプリでは意図的に除外されます（ユーザーは通常、パスキーが存在するデバイスで認証します）。
• トランスポート処理: 主にinternalおよびhybridトランスポートに焦点を当てます。

トランスポートの意味合い:

allowCredentialsには特定の資格情報とそのトランスポートが含まれているため、認証エクスペリエンスを最適化する上でトランスポート処理が非常に重要になります。

セキュリティキーの現実: セキュリティキーは、大規模なコンシューマー展開におけるパスキーの使用の極めてわずかな割合しか占めておらず、主にパワーユーザーや特定のセキュリティ要件を持つユーザーによって使用されます。コンシューマー向けのアプローチは、セキュリティキーを中心に主要なフローを最適化することなく、セキュリティキーをサポートすることでこの現実を認識しています。

2層の作成戦略: 実装では、2つの作成パスを通じて、セキュリティキーの互換性と最適化されたコンシューマーUXのバランスをとることができます。

• ユーザーへのプロンプトと案内: ログイン後のプロンプトと自動作成フローではauthenticatorAttachment: "platform"を使用し、成功率の高い、すぐに利用可能なパスキーにユーザーを導きます。
• Webアカウント設定: authenticatorAttachmentなしの作成を提供し、パワーユーザーがセキュリティキー、サードパーティのパスワードマネージャー、または利用可能な任意のオーセンティケーターを選択できるようにします。

このパターンは主要な実装で見られます。セキュリティキーは設定を介してサポートされ機能しますが、ユーザー向けのアナウンスは、即時のサイレント認証を提供するプラットフォームオーセンティケーターという主要なユースケースに合わせて最適化されています。

最適: コンシューマーアプリケーション、ネイティブのモバイルアプリ、オーセンティケーターの柔軟性よりも合理化されたUXを優先するシナリオ、すでに識別子ファーストのフローが存在するプラットフォーム。

アカウントの存在が漏洩する可能性がすでにあるプラットフォーム、または識別子ファーストのフロー（ユーザーがログインオプションを見る前にメールアドレスを入力する）を使用しているプラットフォームでは、コンシューマー向けのアプローチが自然に適合します。ユーザーが識別子を提供すると、次のようになります。

1. バックエンドが既存のパスキーをクエリします。
2. 特定の資格情報とそのトランスポートを含むallowCredentialsを返します。
3. プラットフォームはトランスポートに基づいて認証UIを最適化できます。
4. 追加のアカウント列挙のリスクはありません（識別子はすでに提供されているため）。

これらのシナリオでは、トランスポートはセキュリティの懸念事項というよりも最適化のツールとなります。デバイスのコンテキスト（モバイルかデスクトップか）と資格情報の機能に基づいて認証オプションを調整できます。

推奨: すでに識別子ファーストのフローを使用しているか、アカウントの列挙が懸念事項ではないプラットフォームの場合、明示的なトランスポート処理を伴うコンシューマー向けのアプローチは、特にpreferImmediatelyAvailableCredentialsがシームレスな生体認証を可能にするネイティブモバイルアプリケーションにおいて、優れたUXを提供します。

internalおよびhybridトランスポートの処理にどちらのアプローチを選択するかにかかわらず、問題を最小限に抑えるために以下のプラクティスに従ってください。

登録中にトランスポートを保存する: 資格情報IDと公開キーとともに、オーセンティケーターの応答からtransports配列を常に保存してください。このデータは認証フローに不可欠です。

空の配列を適切に処理する: iOSのプラットフォームオーセンティケーターから空のトランスポート配列を受け取った場合:

• 仕様準拠: 空のままにするか、トランスポートプロパティを省略します（トランスポート情報が利用できないことを示し、プラットフォームが利用可能なオプションを決定します）。
• 最適化アプローチ: ["internal", "hybrid"] を入力して、表示される認証オプションを制御します。

Webとネイティブのトランスポート戦略: コンテキストに基づいてトランスポートの処理を区別します。

• Web認証: すべてのトランスポートを含め、USB/NFC経由のセキュリティキーを含む、より幅広いオーセンティケーターのサポートを可能にします。
• ネイティブアプリの認証: サイレント認証にはpreferImmediatelyAvailableCredentialsを使用します。トランスポートは保存されたまま送信されます。
• 設定/管理ページ: パワーユーザー向けにすべてのオーセンティケータータイプをサポートします。

セキュリティキー認証を処理する: ユーザーがセキュリティキーを登録している場合:

• Web: 保存された資格情報のセキュリティキートランスポートを検出し、認証フローがそれらに対応できることを確認します。
• ネイティブアプリ: 代替の認証方法を提供するか、セキュリティキー認証のためにユーザーをWebに誘導することを検討してください。
• ハイブリッドアプローチ: ネイティブアプリはプラットフォームオーセンティケーター向けに最適化し、Webは完全なオーセンティケーターの柔軟性をサポートします。

すべてのターゲットプラットフォームでテストする: すべての組み合わせをカバーするテストマトリックスを作成します。

• 登録：Web、iOSネイティブ、Androidネイティブ
• 認証：Web、iOSネイティブ、Androidネイティブ
• preferImmediatelyAvailableCredentialsによるサイレント認証が機能することを確認する
• authenticatorAttachmentなしで設定フローでセキュリティキーが機能することを確認する
• 適切なコンテキストでのみQRコードが表示されることを検証する

トランスポートのセマンティクスを理解する: トランスポートの値が空の場合と欠落している場合の違いを認識します。

• 空のトランスポート配列 []: トランスポート情報が利用できないか、プライバシーのために保留されていることを示します。ユーザーエージェントは、トランスポートの機能を報告できない、または報告しないことを選択した場合に、空のシーケンスを提供することがあります。これは「すべてのトランスポートがサポートされている」ことと同等ではありません。情報が利用できない場合はヒントとして扱います。
• トランスポートプロパティの欠落: トランスポートが資格情報記述子から省略されている場合、ユーザーエージェントは他の要因に基づいて利用可能な認証方法を決定します。コンテキストが重要です。登録応答と認証要求のオプションでは、その意味合いが異なります。
• トランスポートヒント: 仕様によれば、トランスポートは機能の権威ある保証としてではなく、ユーザーエージェントが認証UIを最適化するのを支援するためのヒントとして扱われるべきです。

プラットフォームの変更を監視する: WebAuthnの実装は進化しています。Apple、Google、Microsoftはオーセンティケーターの動作を定期的に更新しています。トランスポートの処理に影響を与える可能性のある変更について常に情報を得てください。

WebAuthnトランスポート（特にinternalおよびhybridトランスポート）は、クロスデバイス認証に実用的な大きな影響を与える技術的な詳細です。トランスポート処理戦略は、広範なパスキー実装アプローチとターゲットプラットフォームに適合している必要があります。

トランスポートの決定は広範な戦略の中に存在する: トランスポートをどのように処理するかは、最大限の柔軟性（空のallowCredentials）のために構築するか、コンシューマーUX（特定の資格情報を使用した識別子ファースト）のために構築するかによって異なります。後者では、トランスポートが最適化にとって重要になります。

プラットフォームの違いには処理が必要: WebとAndroidは信頼できるトランスポート情報を提供しますが、iOSのプラットフォームオーセンティケーターは空の配列を返します。Windows Helloは["internal"]のみを送信します。これらの違いを理解することは、本番環境の展開において不可欠です。

2つの有効なトランスポートアプローチ: 仕様準拠（オーセンティケーターのトランスポートを信頼する）は、エンタープライズや最大の柔軟性が求められるシナリオに適しています。明示的な制御（トランスポートの最適化）は、識別子ファーストのフローを持つコンシューマーアプリケーションやネイティブモバイルアプリに適しています。

識別子ファーストはトランスポートの最適化を可能にする: ユーザーが最初に識別子を提供すると、トランスポート処理は強力なUXツールになります。追加のアカウント列挙の懸念なしに、モバイルでの不要なQRコードの防止、セキュリティキーのオプションの非表示、認証の合理化を行うことができます。

エンタープライズ / 最大の柔軟性向け:

• 空のallowCredentialsを使用して、すべてのオーセンティケータータイプをサポートする。
• オーセンティケーターが提供するトランスポートを信頼する。
• ユーザーに表示される認証オプションが多くなることを受け入れる。
• シンプルな実装、より幅広い互換性。

コンシューマーアプリケーション / ネイティブアプリ向け:

• 識別子ファーストの認証フローを実装する。
• ユーザーへの案内（ログイン後、自動プロンプト）: 成功率の高い即時認証のためにauthenticatorAttachment: "platform"を使用する。
• Webアカウント設定: セキュリティキーを必要とするパワーユーザーのために、authenticatorAttachmentなしの作成を許可する。
• 特定の資格情報と最適化されたトランスポートとともにallowCredentialsを使用する。
• ネイティブアプリ: サイレント認証のためにpreferImmediatelyAvailableCredentialsを有効にする。
• iOSの空の配列を["hybrid", "internal"]で埋める。
• Web認証: セキュリティキーを含むすべてのトランスポートをサポートする。
• 適切な場合、モバイルデバイスでhybridをフィルタリングしてQRコードを防止する。
• 互換性を維持しながら、合理化された認証オプションによる優れたUX。

すでに識別子ファーストのフローを持つプラットフォーム向け:

• アカウント列挙はすでに問題ではない。
• コンシューマー向けのアプローチは、既存のUXと自然に一致する。
• トランスポートの最適化は即時のUXメリットを提供する。
• ほとんどのコンシューマーアプリケーションに対する推奨アプローチ。

仕様準拠から開始し、戦略に基づいて最適化します。

1. 登録中に受信したとおりに正確にトランスポートを保存します。
2. 全体的な戦略（最大の柔軟性 vs コンシューマー向け）を決定します。
3. コンシューマー向けの場合：識別子ファーストフローを実装し、トランスポートを最適化します。
4. 選択した戦略に合わせて、iOSの空の配列を適切に処理します。
5. Web、iOSネイティブ、Androidネイティブのプラットフォーム全体で徹底的にテストします。

WebAuthnを取り巻く環境は進化し続けています。プラットフォームベンダーは実装を定期的に更新しており、WebAuthn Level 3のような仕様は新しい機能を導入しています。トランスポートの処理を広範な認証戦略と整合させる柔軟なシステムを構築することで、パスキー実装は堅牢性を維持し、エコシステムが成熟するにつれて優れたユーザーエクスペリエンスを提供できるようになります。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

iOS AuthenticationServicesは、iCloud キーチェーンのようなプラットフォームオーセンティケーターのトランスポート情報を保留し、WebAuthn仕様のプライバシー条項に従って空の配列を返します。iOS上のセキュリティキーは、["usb"]や["nfc"]のようなトランスポートデータを提供します。リライングパーティは、すべてのトランスポートを機能の権威ある保証ではなく、ヒントとして扱う必要があります。

cableはhybridと同義のレガシー用語であり、caBLE（cloud-assisted Bluetooth Low Energy）の略です。どちらも、スマートフォンを使用してデスクトップセッションを認証するためにQRコードをスキャンするなどのクロスデバイス認証を説明しています。hybridはWebAuthn Level 3で導入された現在の用語であり、新しい実装で使用する必要があります。

識別子ファーストのフローを使用するコンシューマーアプリケーションの場合、登録中に空の配列を返したiOSプラットフォームオーセンティケーターに対して、トランスポートを明示的に["hybrid", "internal"]に設定します。これにより、USBおよびNFCのセキュリティキーのプロンプトが認証UIに表示されるのを防ぎます。仕様に準拠した代替案は、配列を空のままにするか、トランスポートプロパティを完全に省略することです。

モバイル上でhybridトランスポートを削除すると、ユーザーがすでにパスキーが存在するデバイスを使用している場合にQRコードのプロンプトが表示されるのを防ぐことができます。しかし、トランスポートの操作は一貫性のない結果をもたらします。hybridが除外されていてもQRコードを表示するプラットフォームもあれば、関係なく非表示にするプラットフォームもあります。常に対象プラットフォーム全体でテストし、行き止まりが生じないように代替の認証方法を提供してください。

空のallowCredentials配列は、セキュリティキーやクロスデバイス認証を含むすべてのオーセンティケータータイプをサポートしますが、トランスポートの関連性を低下させ、ユーザーに同時に複数のオプションを提示する可能性があります。特定のユーザー資格情報を入力すると、トランスポートの処理がUIを最適化する上で重要になり、識別子ファーストフローでモバイル上のQRコードをフィルタリングし、コンシューマーコンテキストでセキュリティキーのプロンプトを非表示にすることができます。