Sign up to the Passkey Intelligence Webinar on Oct. 8Sign up to the Passkey Intelligence Webinar & learn how to get +80% Passkey Adoption一份完整的指南，教你如何在原生 iOS/Android 应用中测试 1Password、Bitwarden 等密码管理器的 Passkeys 功能。包含测试计划、常见问题及生产就绪策略。
Vincent
Created: October 2, 2025
Updated: October 3, 2025
See the original blog version in English here.
Want to learn how to get +80% Passkey Adoption?
Join our Passkey Intelligence Webinar on October 8.
随着 iOS 17 和 Android 14 的发布，原生移动应用的 Passkeys 生态发生了根本性的变化。第三方密码管理器首次可以作为 Passkey 提供商，打破了 iCloud 钥匙串和 Google 密码管理器 的独占地位。这让用户可以将他们信任的解决方案，如 1Password、Bitwarden 或 Dashlane，带入原生应用的身份验证流程中。虽然这对用户选择权来说是一大胜利，但也给开发者带来了巨大的复杂性。你的 Passkeys 实现在不同的密码管理器和原生移动应用中可能会有不同的表现。因此，任何团队都必须正确测试原生应用 Passkeys 和第三方密码管理器。
这份综合指南将分享我们经过实战检验的方法，用于测试原生应用中第三方密码管理器的 Passkeys 功能。虽然 Passkeys 生态系统在 2025 年已相当成熟，但在实际应用中，我们仍然需要跨越各种密码管理器的实现进行仔细验证。我们将经验总结成一个实用的测试计划，确保你的原生应用能与用户偏爱的密码管理器无缝协作。
Want to learn how to get +80% Passkey Adoption?
Join our Passkey Intelligence Webinar on October 8.
密码管理器生态系统已经超越了平台原生的解决方案。用户会根据自己的特定需求，如跨平台同步、企业功能或隐私偏好，主动选择 1Password、Bitwarden、Dashlane、Proton Pass 和 NordPass 等第三方密码管理器。你的原生 iOS / Android 应用必须适应这种多样性，而不是强迫用户更换他们信任的密码管理工具。
根据我们在 Corbado 页面上测量的数据，我们看到只有 5-10% 的普通用户依赖第三方密码管理器。尽管这个数字听起来可能不高，但如果你在大规模环境中工作，它会对你的 Passkeys 实现的认知度和收到的技术支持工单数量产生巨大影响。我们发现，一些密码管理器对 WebAuthn 规范的实现略有不同，导致用户体验出现细微差异，甚至出现 bug。
原生 iOS 和 Android 应用提供了不同的 Passkey 使用方式。在 Android 上，你会遇到 Passkey 浮层和手动文本框输入来触发 Passkey 流程（对于 Web 应用，Android 也支持 Conditional UI）。iOS 则有自己的 Passkey 浮层、Conditional UI 和手动文本框输入。此外，还有其他边缘情况需要检查。总而言之，你的原生应用必须优雅地处理：
正确的标志位配置决定了 Passkeys 能否在不同设备和平台上按预期工作。关键值包括：
配置错误的标志位不总会立即导致失败。但是，它们可能会造成一些细微的问题和不一致，比如 Passkeys 在一台设备上可用，但在其他设备上却无法同步（即使两台设备上都装了同一个第三方密码管理器）。我们在测试中的一个发现是，一些第三方密码管理器错误地设置了 BE/BS 标志位，这造成了很大一部分 Passkey 问题。
单 Activity (Android) 和单 Scene
(iOS) 的架构需要精细的生命周期管理。当密码管理器窗口出现又被关闭时，你的应用必须保持状态、处理回调并正确恢复。这在 Android 上尤其关键，因为
launchMode 的配置可能会导致意外行为。
例如，我们发现将 MainActivity 设置为 launchMode="singleInstance"
会产生问题。在某些 Android 版本和 OEM 定制系统中，此模式会导致 Passkey 凭据管理器 UI 作为一个单独的任务打开。这不仅在“最近应用”屏幕中增加了一个令人困惑的额外应用条目，还可能在 Passkey 对话框打开时，如果应用被切换到后台，导致应用挂起。
推荐的修复方法是将配置更改为
launchMode="singleTask"。这可以防止凭据管理器生成一个单独的任务，从而确保在不同 OEM（三星、谷歌、Vivo 等）之间有更可预测的生命周期，并降低了特定于供应商的 bug 的风险。它为测试导航、浮层和深度链接提供了更稳定的基础。
我们观察到，这类生命周期问题常常被误认为是“密码管理器 bug”，而实际上它们是应用层面的问题。通过在不同提供商之间进行适当的检测和测试，有助于及早发现这些模式。
将你的原生应用 Passkey 测试重点放在最广泛使用的第三方密码管理器上：
主要目标（基本覆盖）：
次要目标（根据你的用户群）：
避免试图测试所有可用的密码管理器。专注于那些能代表你 90% 用户群的提供商。我们的分析显示，在欧盟/美国/英国/澳大利亚/新西兰地区，上述五个主要目标覆盖了 85% 的第三方密码管理器用户。
在开始每次测试前，确保一个干净、可复现的环境：
1. 清理凭据状态：
2. 稳定测试环境：
每个测试都验证 Passkey 功能的特定方面。系统地记录结果，使用通过/失败状态，并为任何异常情况附上详细说明。
验证优雅的取消处理
✓ 密码管理器窗口正常打开 ✓ 用户取消操作，未创建 Passkey ✓ 应用返回登录屏幕 ✓ 密码管理器中没有残留的凭据 ✓ UI 显示适当的重试选项
验证身份验证流程后的 Passkey 创建
✓ 本地身份验证可靠地启动 ✓ 生物识别身份验证成功完成 ✓ 凭据以正确的 RP ID 创建 ✓ 应用转换到已验证状态，没有循环
测试标准身份验证场景
✓ Passkey 浮层 UI 出现，或用户在文本框场景中提供用户名 ✓ 生物识别扫描和单一生物识别提示成功完成身份验证 ✓ 没有选择循环或窗口重新出现 ✓ 身份验证后会话保持稳定
验证应用内的 Passkey 管理
✓ 正确的 RP ID、可发现性以及 BE/BS 标志位 ✓ 创建后应用保持已验证状态 ✓ 密码管理器立即更新并显示正确的标签
测试凭据生命周期管理
✓ 在设置中删除 Passkey ✓ 无法进行 Passkey 登录 ✓ 提供了合适的回退选项
验证应用到 Web 的可移植性
✓ 浏览器识别出应用创建的 Passkeys ✓ 选择窗口显示正确的 RP 关联 ✓ 身份验证完成，无需通过二维码/CDA 绕行
测试 Web 到应用的凭据共享
✓ 应用在选择列表中显示 Web 创建的凭据 ✓ 首次尝试身份验证成功 ✓ 未强制回退到密码
验证从原生应用到桌面浏览器的 Passkey 同步
✓ 应用创建的 Passkey 同步到桌面密码管理器 ✓ 同步的 Passkey 在桌面浏览器中无缝工作 ✓ 未触发二维码 / 跨设备流程 ✓ 身份验证完成，没有循环或错误
验证从桌面浏览器到原生应用的 Passkey 同步
✓ 桌面创建的 Passkey 同步到移动密码管理器 ✓ 原生应用正确显示同步的 Passkey ✓ 身份验证成功，没有密码回退 ✓ 日志将 assertion 与正确的 credential ID 关联
验证手机作为安全密钥的场景
✓ 手机为 Web CDA 提供了应用创建的凭据 ✓ 没有“无可用 Passkeys”的错误提示 ✓ 在移动设备生物识别后 Web 会话完成
我们广泛的测试揭示了一些影响第三方密码管理器 Passkey 集成的常见模式：
问题： 在一台设备上创建的凭据可能不会立即出现在其他设备上。
解决方案： 实现带有指数退避的重试逻辑。为遇到同步延迟的用户提供手动刷新选项。
问题： 密码管理器的行为在不同操作系统版本之间差异很大，尤其是在 Android 14+ 和 iOS 17+ 上。
解决方案： 维护一个兼容性矩阵，并根据检测到的操作系统版本调整流程。考虑设置最低版本要求以获得最佳体验。
在原生应用中成功实现第三方密码管理器的 Passkey 支持，需要有条不紊的测试和对细节的关注。我们全面的测试计划，经过真实世界测试的提炼，为验证你的 Passkey 集成提供了坚实的基础。
生产部署的关键要点：
Passkey 生态系统在持续快速发展。密码管理器会定期更新其实现，操作系统会引入新功能，WebAuthn 规范本身也在进步。通过现在建立一个强大的测试框架，你将为技术成熟时的适应做好准备。
随着新模式的出现，我们将继续更新我们的 SDK 和测试方法。对第三方密码管理器进行全面测试的投入，将以减少支持负担和提高用户满意度的形式回报。毕竟，无论你的用户选择哪个密码管理器，身份验证都应该顺畅无阻。
Share this article
Related Articles
Table of Contents
