WebAuthn传输：内部与混合传输

企业 Passkey 白皮书. 面向 passkey 项目的实用指南、推广模式和 KPI。

获取白皮书

注：根据WebAuthn规范，空的传输序列意味着传输信息不可用或出于隐私原因被保留。通常被浏览器视为可能支持所有传输。

在跨平台实施通行密钥时，开发人员面临一个重要决定：

• 应如何处理WebAuthn传输（尤其是内部和混合传输），以确保最佳的跨设备身份验证体验？

答案在于理解WebAuthn传输——这是一个决定身份验证器如何与依赖方进行通信的技术细节。虽然传输在理论上看似简单，但它们在Web浏览器、原生iOS和原生Android应用程序中的实现差异巨大，特别是在内部和混合传输的处理上。

本文探讨了WebAuthn传输在不同平台上的运作方式，并提出了两种处理内部和混合传输的不同方法——每种方法都有其自身的权衡。

本文涵盖：

1. WebAuthn传输：跨Web、iOS和Android的内部、混合及平台身份验证器
2. 两种方法：符合规范 vs. 优化的内部与混合传输处理
3. 跨设备身份验证实施最佳实践与建议

WebAuthn传输定义了身份验证器与客户端设备之间的通信方法。 WebAuthn Level 3规范 定义了六种传输类型：

usb：用于通过USB端口连接的硬件安全密钥，例如YubiKeys或其他FIDO2安全令牌。

nfc：支持通过近场通信（NFC）与身份验证器进行通信，允许用户触碰其安全密钥或支持NFC的设备。

ble：支持通过低功耗蓝牙（Bluetooth Low Energy）进行身份验证，实现与外部身份验证器的无线通信。

smart-card：用于智能卡读卡器，允许通过智能卡进行身份验证。

hybrid：支持跨设备身份验证，通常是用户扫描二维码在不同设备间进行身份验证——例如使用手机在桌面浏览器上进行身份验证，反之亦然。此传输可在桌面和移动设备上同时触发二维码提示，根据上下文这可能并不总是理想的做法。注：hybrid 是在WebAuthn Level 3中引入的。

internal：身份验证器嵌入在设备本身中——比如iPhone上的iCloud钥匙串（通过Face ID或Touch ID验证）、PC上的Windows Hello，或Android设备上的Google Password Manager。这些属于平台身份验证器。

当创建通行密钥时，身份验证器会发送其支持的传输信号。此信息会被发送到依赖方（您的后端），您应该将其与凭据一起持久化保存。在身份验证期间，依赖方会在 allowCredentials 列表中将这些传输发回给客户端，以帮助浏览器或平台确定向用户提供哪些身份验证方法。

各平台在传输处理方面差异显著，这也是开发人员面临兼容性挑战的原因。

浏览器从身份验证器接收传输信息，并在身份验证流程中遵循它。在Chrome、Safari或Edge中创建通行密钥时，浏览器的凭据管理器会根据底层身份验证器提供不同的传输数据：

平台身份验证器：Windows Hello 仅提供 ["internal"]，反映了其设备绑定的特性。然而，当Chrome使用Google Password Manager作为身份验证器时，它会提供 ["internal", "hybrid"]，因为Google Password Manager支持通过Android手机进行跨设备身份验证。

硬件安全密钥：根据其实际功能提供特定的传输，如 ["usb", "nfc"]。

云同步的凭据管理器：Safari中的iCloud钥匙串和Chrome中的Google Password Manager通常提供 ["internal", "hybrid"]，以支持本地和跨设备身份验证流程。

在Web上下文中，此信息的流动是可靠的，具体传输取决于浏览器选择哪个身份验证器进行凭据存储。

文档： W3C WebAuthn规范

Android的 Credential Manager API 行为与Web浏览器类似。在原生Android应用中创建通行密钥时，凭据管理器提供的传输信息与Web行为一致——平台身份验证器准确报告其功能，并且系统一致地处理传输数据。Android开发人员可以依赖这些信息，而无需进行特殊处理。

文档： Android凭据管理器

iOS的情况更为复杂。Apple的 AuthenticationServices框架 根据身份验证器类型不同地处理传输：

平台身份验证器（iCloud钥匙串，通过Face ID或Touch ID验证）：在通行密钥创建期间，往往返回空的传输数组。这表明传输信息不可用或出于隐私考虑被保留——根据WebAuthn规范，当传输信息未知或为了保护隐私时，用户代理可以返回空序列。依赖方应将传输视为提示而非保证。

安全密钥：与iOS设备一起使用时，确实会提供传输信息（例如 ["usb"]，["nfc"]），遵循了预期模式。

文档： Apple AuthenticationServices

来自Web和原生应用程序的实际生产数据显示了以下传输模式（按频率排序）。请注意，这些分布受实施细节和客户端受众特征（移动端 vs 桌面端使用情况、原生应用的可用性）的影响，但它们为典型的传输使用情况提供了有价值的参考：

核心洞察：

平台身份验证器占据主导：绝大多数通行密钥使用 internal 传输，通常结合 hybrid 以支持跨设备身份验证。这反映了以平台身份验证器（iCloud钥匙串，Google Password Manager）为重点的消费者趋势。

空数组很常见：iOS原生应用程序经常针对平台身份验证器返回空的传输数组，这在生产环境凭据中占有很大比例。如第2.2.3节所述，这些表示传输信息不可用，而非提供全面的传输支持。

安全密钥很少见：硬件安全密钥（usb，nfc）在生产环境通行密钥中只占极小的一部分，表明它们主要用于企业或高安全场景，而非消费者应用。

存在顺序变化：数组中传输的顺序（["internal", "hybrid"] vs ["hybrid", "internal"]）因平台和身份验证器实现而异，但在功能上没有区别——两者均表示支持相同的传输方法。

旧版术语：cable 传输标识符偶尔出现在较旧的实现中，它是 hybrid 的同义词（caBLE = 云辅助低功耗蓝牙 Energy，是hybrid传输的原始名称）。

这一分布强调了正确处理 internal 和 hybrid 传输的重要性，因为它们占据了现实世界通行密钥实现的绝大多数。

传输的可用性显示的是身份验证器报告的内容，而不是该流程最终是否能够完成。Corbado 2026年通行密钥基准测试的跨设备身份验证完成率分析 测量出，2026年第一季度通过 hybrid 传输的完成率在Windows Web端整体为60%至78%，在macOS Web端为66%至86%。具体细分为：同设备提示场景（Windows端79%至98% / macOS端83%至98%），而标识符优先流程（Windows端52%至67% / macOS端59%至76%）。请在路由逻辑中将 hybrid 视为成本最高的传输方式，并优先选择让用户停留在持有凭据的设备上的流程。

相同的身份验证器通常会根据平台、版本和实施上下文报告不同的传输模式。这种变化是正常且符合预期的：

iCloud钥匙串 呈现出三种模式：

• ["internal", "hybrid"] - 最常见，通常来自Web浏览器
• [] （空数组） - 非常常见，来自iOS原生应用
• ["hybrid", "internal"] - 较不常见，顺序变化
• 仅 ["internal"] 或 ["hybrid"] - 罕见的边缘情况

Google Password Manager 变化最多：

• ["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 vs 原生、iOS vs Android，或Windows vs macOS上的行为不同。

版本演进：传输报告随着时间的推移而发展。旧版本可能使用 cable 代替 hybrid，或报告不同的组合。

实施选择：部分身份验证器优先考虑 internal，其他则优先 hybrid。该顺序没有功能影响，但因实施而异。

上下文敏感性：原生应用（尤其是在iOS上）经常接收到空数组，即便是那些在Web上下文中报告完整传输的身份验证器也会如此。

核心要点：不要假设某个身份验证器的传输数组始终是一致的。您的实施应被设计为优雅地处理所有变化，重点关注特定传输的存在与否，而不是精确的数组匹配。

开发人员面临一个选择：是严格遵循规范，还是针对用户体验优化内部和混合传输。每种方法都有其优缺点。

这种方法严格遵循WebAuthn规范：在凭据注册期间完全按照身份验证器提供的传输进行使用，并在身份验证期间原样发送回它们。

实施：创建通行密钥时，持久化来自身份验证器响应的 transports 数组。在身份验证期间，在 allowCredentials 列表中包含这些确切的传输：

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

优点：

• 合规性：严格遵循WebAuthn标准，确保与未来平台更新的兼容性
• 安全密钥可靠性：对硬件安全密钥（YubiKeys等）完美生效，它们始终提供准确的传输信息
• 防止无效选项：避免提供真正不支持的身份验证方法——例如，不会触发针对Windows Hello凭据的二维码

缺点：

• iOS空数组行为：iOS上的平台身份验证器返回空的传输数组，这表示传输信息不可用——各平台在决定显示哪些身份验证选项时可能会有不同的解释
• 可能会显示不想要的选项：可能会在不期望看到它们（如USB、NFC）的消费者应用程序中呈现安全密钥选项
• 用户体验不一致：不同平台针对同一账户提供不同的身份验证选项

最适用场景：优先考虑标准合规性的应用程序，以及具有多种类型身份验证器的企业环境。

此方法优先考虑用户体验，根据特定的优化目标选择性地修改内部和混合传输。不要使用一刀切的规则，请考虑以下常见的优化场景：

问题：iOS平台身份验证器返回空的传输数组。当数组留空或由后端填充时，用户可能会看到安全密钥提示（USB、NFC）与平台选项并列出现，在消费者应用程序中造成困惑。

解决方案：将iOS平台身份验证器的传输显式设置为 ["hybrid", "internal"]。这确保仅提供平台身份验证和跨设备流程，隐藏了安全密钥选项。

// 持久化iOS平台身份验证器凭据时
if (platform === "iOS" && authenticatorAttachment === "platform") {
    transports = ["hybrid", "internal"];
}

结果：对于在iOS上创建的通行密钥，身份验证UI整洁且没有安全密钥提示。

问题：在移动设备上进行身份验证时，显示跨设备身份验证的二维码会带来糟糕的UX——用户已经在使用一台通行密钥可用的移动设备。

解决方案：当用户从移动设备进行身份验证时移除 hybrid 传输，仅留下 ["internal"]。

// 构建用于身份验证的allowCredentials时
const transports = isMobileDevice
    ? credentials.transports.filter((t) => t !== "hybrid")
    : credentials.transports;

结果：移动端用户仅看到直接的身份验证选项，没有多余的二维码提示。

⚠️ 警告：传输操作并不总能在各平台上产生一致的结果。广泛的测试表明，浏览器和操作系统的组合处理传输的方式存在差异：

• 某些平台即使从传输中排除了 hybrid，也会显示二维码
• 另一些平台即使包含了 hybrid，也会隐藏二维码
• 在Windows、macOS和iOS上，Chrome、Edge、Safari和Firefox之间的行为差异显著

出现死胡同的风险：过于严格的传输过滤可能会创建身份验证死胡同，使用户根本无法登录。例如，移除 hybrid 可能会阻止合理的跨设备身份验证场景（如用户需要从借来的设备进行身份验证）。在部署传输优化前，请务必提供后备身份验证方法，并在目标平台上进行全面测试。

这些是优化提示：除了传输操作，WebAuthn还提供了其他机制来优化身份验证UX，比如 hints（提示）。

传输行为不可预测：通过 hybrid 传输进行的跨设备身份验证（CDA）在浏览器和操作系统的各种组合中表现出不一致的行为。真实的测试表明，传输值并不能保证特定的UI行为——各平台对传输的解释和处理不同，导致意想不到的结果。

特定平台的复杂性：当显式控制传输时，您必须考虑平台差异：

• iOS：发送针对平台身份验证器的空数组；需要进行填充
• Windows Hello：必须保持仅 ["internal"]；添加 hybrid 会触发不想要的二维码
• Web和Android：通常提供准确的传输信息
• CDA的变化：无论传输数组中是否存在 hybrid，二维码提示都可能会出现或消失

需要端到端的理解：显式控制传输意味着要对整个流程负责。您必须了解每种传输组合在所有目标平台上的行为，并进行彻底测试。传输操作可能会产生身份验证死胡同，即用户没有任何有效的身份验证路径。

优点：

• 量身定制的UX：精确控制用户在特定上下文中看到的身份验证选项
• 解决iOS空数组问题：在iOS没有提供传输的地方显式定义传输
• 上下文感知优化：根据设备类型调整身份验证UI

缺点：

• 不可预测的行为：传输操作不保证一致的UI行为——大量测试显示各平台解释传输的方式不同，有时无论传输值为何都会显示或隐藏选项
• 身份验证死胡同风险：过于严格的传输过滤会阻止用户登录，尤其在跨设备场景中
• 偏离规范：脱离了规范建议，可能导致与未来的平台变化产生问题
• 维护负担：需要随着平台演进而持续进行针对特定平台的逻辑和更新
• 复杂性：必须手动处理iOS空数组、Windows Hello的限制及其他平台特性
• 测试开销：每条优化规则都需要在所有平台组合中进行验证

最适用场景：对UX有特定要求的消费者应用、有资源维护平台特定逻辑的团队，以及优先考虑精简身份验证流程而非严格遵循规范的场景。

WebAuthn传输处理并非孤立存在——它是您整体通行密钥实施策略的一部分。在生产部署中出现了两种常见的方法，每种方法对内部和混合传输的使用都有不同的影响。

该方法优先考虑灵活性和标准合规性，允许用户使用任何兼容的身份验证器进行身份验证。

实施特点：

• 身份验证UI：通行密钥按钮与现有的登录选项（用户名/密码）并列出现
• allowCredentials：设置为空数组 []，允许匹配任何凭据
• 身份验证器类型：全面支持安全密钥、跨设备身份验证（二维码）、平台身份验证器
• 原生应用要求：必须支持所有身份验证方法，包括安全密钥
• preferImmediatelyAvailableCredentials：不能使用，因为根据定义，它排除了安全密钥和二维码登录
• 传输处理：必须容纳所有传输类型，包括安全密钥传输（usb，nfc，ble）

传输影响：

如果 allowCredentials 为空，在身份验证期间传输就不那么关键了——平台会显示所有可用选项。然而，这意味着用户可能会同时看到安全密钥提示、二维码和平台选项，这可能会在消费者应用中引起决策瘫痪。

最适用场景：企业环境、需要安全密钥支持且用户群多样的应用程序，以及优先追求最大身份验证灵活性的场景。

此方法通过将通行密钥的创建限制为平台身份验证器并使用标识符优先（identifier-first）流程，为消费者UX进行了优化。

实施特点：

• 通行密钥创建：用户发起的提示（登录后提示、自动创建流程）使用 authenticatorAttachment: "platform" 来专注那些立即可用的身份验证器
• 安全密钥支持：在Web帐户设置中提供，不带有 authenticatorAttachment 限制，允许高级用户选择任何身份验证器，包括安全密钥
• 身份验证流程：标识符优先——用户在进行身份验证之前输入电子邮件/用户名
• allowCredentials：一旦知晓标识符，就使用用户特定的凭据进行填充（非空）
• 身份验证器类型：优先考虑平台身份验证器和跨设备身份验证；支持安全密钥，但不在主要流程中进行推广
• 原生应用优化：使用 preferImmediatelyAvailableCredentials 实现静默、即时的身份验证，而无需进行安全密钥或二维码提示
• 跨设备身份验证：在Web上可用；当使用 preferImmediatelyAvailableCredentials 时，会在原生应用中有意排除（用户通常在具有其通行密钥的设备上进行身份验证）
• 传输处理：主要聚焦于 internal 和 hybrid 传输

传输影响：

由于 allowCredentials 包含特定凭据及其传输，传输处理在优化身份验证体验时变得至关重要。

安全密钥的现状：在大型消费者部署中，安全密钥仅占通行密钥使用量的极小部分——主要针对高级用户或有特定安全需求的用户。为消费者量身定制的方法认可了这一现实，在不围绕安全密钥优化主流程的同时支持它们。

双层创建策略：实现方案可通过双重创建路径来平衡安全密钥的兼容性与优化的消费者UX：

• 用户提示和引导：登录后提示和自动创建流程使用 authenticatorAttachment: "platform"，引导用户走向具有高成功率的立即可用通行密钥
• Web帐户设置：提供没有 authenticatorAttachment 的创建，允许高级用户选择安全密钥、第三方密码管理器或任何可用的身份验证器

这一模式出现在一些大型实施案例中：安全密钥受支持并可通过设置生效，但面向用户的提示针对主要使用案例进行了优化——提供即时、静默身份验证的平台身份验证器。

最适用场景：消费者应用、原生移动应用、优先考虑简化UX而非身份验证器灵活性的场景，以及已经存在标识符优先流程的平台。

对于已经泄露账户存在性或使用标识符优先流程（用户在看到登录选项之前先输入电子邮件）的平台来说，消费者定制的方法自然契合。一旦用户提供了他们的标识符：

1. 后端查询现有通行密钥
2. 带着特定凭据及其传输返回 allowCredentials
3. 平台可根据传输优化身份验证UI
4. 没有额外的账户枚举风险（标识符已提供）

在这些场景中，传输可以成为一种优化工具，而不是安全问题。您可以根据设备上下文（移动端 vs 桌面端）和凭据功能来定制身份验证选项。

建议：对于已经使用标识符优先流程或无需担心帐户枚举的平台，带有显式传输处理的消费者定制方法能提供卓越的UX，特别是在原生移动应用程序中，preferImmediatelyAvailableCredentials 支持了无缝的生物识别身份验证。

无论您选择哪种方法处理内部和混合传输，请遵循以下实践以尽量减少问题：

注册期间持久化传输：始终将身份验证器响应中的 transports 数组与凭据ID和公钥一起存储。此数据对身份验证流程至关重要。

优雅处理空数组：当从iOS平台身份验证器接收到空的传输数组时：

• 符合规范：留空或省略传输属性——表示传输信息不可用；平台将决定可用的选项
• 优化方法：填充为 ["internal", "hybrid"] 以控制显示哪些身份验证选项

Web vs 原生传输策略：根据上下文区分传输处理：

• Web身份验证：包含所有传输，允许更广泛的身份验证器支持，包括通过USB/NFC连接的安全密钥
• 原生应用身份验证：对于静默身份验证，使用 preferImmediatelyAvailableCredentials；传输按存储的发送
• 设置/管理页面：为高级用户支持所有身份验证器类型

处理安全密钥身份验证：当用户注册了安全密钥时：

• Web端：检测存储凭据中的安全密钥传输，确保身份验证流程能够容纳它们
• 原生应用：考虑提供后备身份验证方法，或引导用户至Web以进行安全密钥身份验证
• 混合方案：原生应用针对平台身份验证器进行优化，而Web端则支持全面的身份验证器灵活性

在所有目标平台上测试：创建一个覆盖所有组合的测试矩阵：

• 注册：Web端、iOS原生、Android原生
• 身份验证：Web端、iOS原生、Android原生
• 验证具有 preferImmediatelyAvailableCredentials 的静默身份验证是否正常工作
• 确认没有 authenticatorAttachment 的情况下，安全密钥在设置流程中是否正常工作
• 验证二维码是否仅在合适的上下文中出现

理解传输语义：认识到空传输值和缺少传输值之间的区别：

• 空传输数组 []：表示传输信息不可用或因隐私被保留。当用户代理不能或选择不报告传输能力时，可能会提供空序列。这并不等同于“支持所有传输”——在信息不可用的地方应将其视为提示。
• 缺少的传输属性：从凭据描述符中省略传输时，用户代理将根据其他因素确定可用的身份验证方法。上下文很重要：在注册响应与身份验证请求选项中，其含义有所不同。
• 传输提示：根据规范，应将传输视为帮助用户代理优化身份验证UI的提示，而不是关于功能的权威保证。

关注平台变更：WebAuthn实现正在不断发展。Apple、Google和Microsoft会定期更新其身份验证器行为。随时了解可能影响传输处理的变更。

WebAuthn传输——特别是内部和混合传输——是对跨设备身份验证具有显著实际影响的技术细节。您的传输处理策略应该与您更广泛的通行密钥实施方案和目标平台保持一致。

传输决策存在于更广泛的策略之中：如何处理传输取决于您是追求最大灵活性（允许空的 allowCredentials），还是注重消费者UX（标识符优先，使用特定凭据）。后者使得传输成为优化的关键。

平台差异需要进行处理：Web和Android提供可靠的传输信息，而iOS平台身份验证器则返回空数组。Windows Hello仅发送 ["internal"]。了解这些差异对于生产部署至关重要。

两种有效的传输方法：符合规范（信任身份验证器传输）适用于企业和最大灵活性的场景。显式控制（优化传输）则适合具有标识符优先流程的消费者应用及原生移动应用。

标识符优先实现传输优化：当用户先提供其标识符时，传输处理就会成为一个强大的UX工具。您可以防止移动设备上出现不需要的二维码，隐藏安全密钥选项并简化身份验证——而无需增加有关帐户枚举的担忧。

面向企业 / 最大灵活性：

• 使用空的 allowCredentials 支持所有身份验证器类型
• 信任身份验证器提供的传输
• 接受用户会看到更多的身份验证选项
• 实施更简单，兼容性更广

面向消费者应用程序 / 原生应用：

• 实施标识符优先的身份验证流程
• 用户提示（登录后，自动提示）：使用 authenticatorAttachment: "platform" 以获得高成功率即时身份验证
• Web帐户设置：允许不带 authenticatorAttachment 创建，给需要安全密钥的高级用户使用
• 将 allowCredentials 与特定凭据及优化的传输一起使用
• 原生应用：为静默身份验证启用 preferImmediatelyAvailableCredentials
• 使用 ["hybrid", "internal"] 填充iOS空数组
• Web身份验证：支持所有传输（包括安全密钥）
• 在适当的时候，于移动设备上过滤 hybrid 以防止出现二维码
• 在保持兼容性的同时提供具有简化身份验证选项的卓越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 工具看不到的内容：哪些设备、操作系统版本、浏览器和 credential manager 支持 passkey，为什么注册没有转化为登录，WebAuthn 流程在哪里失败，以及什么时候操作系统或浏览器更新会悄悄破坏登录 — 而且无需替换 Okta、Auth0、Ping、Cognito 或你自有的 IDP。两款产品：Corbado Observe 提供 针对 passkey 及任何其他登录方式的 observability。Corbado Connect 提供 内置 analytics 的 managed passkey（与你的 IDP 并存）。VicRoads 通过 Corbado 为 500 万以上用户运行 passkey（passkey 激活率 +80%）。 与 Passkey 专家交谈 →

根据WebAuthn规范的隐私规定，iOS AuthenticationServices针对像iCloud钥匙串这样的平台身份验证器保留了传输信息，返回空数组。在iOS上的安全密钥确实会提供如 ["usb"] 或 ["nfc"] 的传输数据。依赖方应将所有传输视为提示，而不是功能的权威保证。

cable 是旧版术语，是 hybrid 的同义词，代表caBLE（云辅助低功耗蓝牙）。两者都描述跨设备身份验证，例如扫描二维码以使用手机验证桌面会话。hybrid 是在WebAuthn Level 3中引入的现行术语，应在新的实现中使用。

对于使用标识符优先流程的消费者应用程序，请针对在注册期间返回空数组的iOS平台身份验证器显式将传输设置为 ["hybrid", "internal"]。这可以防止在身份验证UI中出现USB和NFC安全密钥提示。符合规范的替代方法是将数组留空，或完全省略该传输属性。

在移动端移除 hybrid 传输，可防止用户处于其实际存有通行密钥的设备上时，依然出现二维码提示。但是，传输操作会产生不一致的结果：即使排除了 hybrid，某些平台仍会显示二维码，而有些平台则无论如何都会将其隐藏。始终跨目标平台进行测试，并提供备用的身份验证方法，以避免造成死胡同。

空的 allowCredentials 数组支持所有身份验证器类型（包括安全密钥和跨设备身份验证），但这降低了传输的相关性，并且可能会同时向用户展示多个选项。将其填充为特定的用户凭据则使得传输处理对于优化UI变得至关重要，这能够支持标识符优先流程以在移动端过滤二维码，并在消费者上下文中隐藏安全密钥提示。