---
url: 'https://www.corbado.com/zh/blog/passkey-day-2-problems'
title: '通行密钥的第二天问题：发布后的 5 大风险'
description: '通行密钥很棒，除非您的部署方式有误。了解围绕恢复、跨设备体验、原生应用、采用率和平台更改的 5 个“第二天”问题。'
lang: 'zh'
author: 'Vincent Delitz'
date: '2026-05-27T11:04:38.759Z'
lastModified: '2026-05-27T11:06:20.898Z'
keywords: '通行密钥第二天问题, 通行密钥运营挑战, 通行密钥发布风险, 通行密钥生产问题, 是否应该实施通行密钥'
category: 'Passkeys Strategy'
---

# 通行密钥的第二天问题：发布后的 5 大风险

## Key Facts

- **采用率低**是最常见的失败原因：如果企业跳过推广策略，即使技术实现非常完善，通行密钥的使用率也会低于 5%，从而使整个工程投资付诸东流。
- **恢复与回退设计**决定了您是大规模将用户拒之门外，还是重新引入网络钓鱼风险。如果攻击者控制了收件箱，基于电子邮件的重置将完全绕过抗钓鱼的通行密钥。
- **平台更改**会在暗中破坏通行密钥，例如 iOS 26.2 中的一个错误导致 `isUserVerifyingPlatformAuthenticatorAvailable()` 在所有非 Safari 浏览器上均返回 false，这需要更新检测逻辑。
- **原生应用复杂性**使 Web、iOS 和 Android 端的质量保证 (QA) 工作量增加了两倍，特定平台的错误代码和应用商店审核周期会阻碍紧急的通行密钥回归修复。

## 1. 简介：发布后的通行密钥风险

**不要实施通行密钥。**

至少，如果您没有足够的资源来正确地实施，就不要不惜一切代价地去实施。

是的，通行密钥是过去十年来消费者身份验证领域发生的最美好的事情。是的，它们消除了网络钓鱼。是的，它们可以大幅提升用户体验。但是，如果实施不当，通行密钥也可能造成很大的危害。

实施 WebAuthn 服务器并不太复杂。真正的挑战在于围绕它的一切。要大规模地高效运营通行密钥，需要提前规划。您需要考虑所有的“第二天”问题——这些运营现实只有在您开始推广通行密钥后才会浮出水面。

本文涵盖了始终会导致通行密钥项目失败的五个“第二天”问题。如果您不能解决所有这些问题，您就没有准备好发布通行密钥。如果您能解决，您将构建出比密码更安全、更易用的身份验证系统。

## 2. 什么是通行密钥的“第二天”问题？

在工程领域，“第一天”是您构建和发布的时候。“第二天”是您运营、维护和扩展所发布内容的时候。对于通行密钥而言，第一天可能很简单：

- 将 WebAuthn 服务器集成到您的企业技术栈中
- 添加前端流程并启动。

大多数团队可以在几天或几周内运行一个基础的通行密钥实现。

第二天才是项目容易失败的地方。此时真实用户在真实设备上带着真实的边缘情况与您的通行密钥系统进行交互。此时您会发现，在您的 MacBook 上完美运行的漂亮演示，却在企业代理后面的运行 Chrome 的 Windows 笔记本电脑上崩溃了。此时您的支持团队会被“我无法登录了”的工单淹没。

一个正常工作的通行密钥演示与生产级通行密钥部署之间的差距是巨大的。我们之前已经探讨过技术实施陷阱和通行密钥项目失败的战略原因。本文专门从运营的角度重点讨论上线后会发生什么。

以下是我们即将讨论的五个“第二天”问题：

- [问题 1：恢复和回退难以保障安全](#3-issue-1-recovery-and-fallback-are-hard-to-secure)
- [问题 2：跨设备和跨生态系统的边缘情况会破坏通行密钥流程](#4-issue-2-cross-device-and-cross-ecosystem-edge-cases-break-passkey-flows)
- [问题 3：原生应用成倍增加通行密钥的复杂性](#5-issue-3-native-apps-multiply-passkey-complexity)
- [问题 4：采用率是产品问题，而非技术问题](#6-issue-4-adoption-is-a-product-problem-not-a-tech-problem)
- [问题 5：平台更改会在暗中破坏通行密钥](#7-issue-5-platform-changes-break-passkeys-silently)

## 3. 问题 1：恢复和回退难以保障安全

如果您没有正确设计恢复和回退机制，您要么会大规模地将用户拒之门外，要么会在悄无声息中重新引入您原本想消除的容易遭受钓鱼攻击的流程。

### 3.1 大规模的帐户锁定风险

假设一位用户在他们的 iPhone 上注册了一个通行密钥，然后丢失了这部 iPhone。通常情况下，现在这类恢复案例很大一部分是由凭证管理器（在 iPhone 上很可能是 iCloud 钥匙串）处理的。只要用户能够访问他们的 Apple 帐户，他们就可以在新设备上使用同步的通行密钥登录。但是如果他们无法再访问那个云帐户怎么办？这就需要您的常规恢复路径发挥作用了。

假设您认为用户尝试登录的设备上仍然存在私钥，因此您启动了 WebAuthn 登录仪式。这将弹出一个操作系统/浏览器模态框，要求用户“在另一台设备上使用您的通行密钥登录”。基本上，用户现在被锁在他们的帐户之外了。没有其他设备存储了该通行密钥。用户会感到非常困惑。将其乘以成千上万的用户，您就会面临一场支持危机。

常见的反应是添加基于电子邮件的帐户重置作为回退机制。但这违背了通行密钥的初衷：您刚刚重新引入了一个容易受到网络钓鱼攻击的恢复渠道。一个能够攻破用户电子邮件的攻击者现在可以完全绕过您抗钓鱼的通行密钥实现。

### 3.2 在不重新引入网络钓鱼的情况下设计回退机制

在我们看来，正确的方法是分层恢复：

1. **同步的通行密钥**作为主要策略：确保用户创建同步的通行密钥（通过 iCloud 钥匙串、Google 密码管理器或第三方通行密钥提供商），这样设备丢失不意味着凭证丢失。
2. **跨设备身份验证**作为第二层：允许用户通过扫描二维码，从存有另一个通行密钥的另一台设备进行身份验证。
3. **身份验证 (IDV)** 作为第三层：提供带有活体检测的自动化 IDV，而不是回退到密码/OTP。
4. **数字可验证凭证**作为第四层：这是最安全、最保护隐私且用户体验最友好的帐户恢复方式。这允许用户使用他们的数字可验证凭证（例如数字国民身份证或 mDL），通过标准 API（例如 Digital Credentials API）来验证他们的身份。这项技术相当新，采用率不高，但在未来几个月和几年内将发挥重要作用。

一般来说，您需要决定从成本/摩擦的角度来看，哪些帐户恢复层是合理的。例如，在[零售](https://www.corbado.com/passkeys-for-e-commerce) / [电子商务](https://www.corbado.com/passkeys-for-e-commerce)中，出于财务原因，您可能只提供前两层并接受网络钓鱼风险。在安全性更为重要的其他行业中，您可以采用第 3 层和第 4 层。

每一层都会增加复杂性。您需要决定您的用例需要哪些层，构建它们，在所有设备组合中测试它们，并监控它们的使用情况。这比最初的 WebAuthn 集成要做的工作多得多。

### 3.3 大多数团队的错误做法

大多数团队要么过度简化恢复（回退到密码或 SMS OTP），要么过度复杂化（例如，要求每次恢复都使用硬件安全密钥）。正确的平衡取决于您的威胁模型、用户群和监管要求。做错了意味着要么破坏您的安全态势，要么制造太多摩擦导致用户放弃该流程。

## 4. 问题 2：跨设备和跨生态系统的边缘情况会破坏通行密钥流程

您的用户并不生活在一个纯净的 Apple 世界中。他们会更换设备，将 Windows 与 iOS 混合使用，使用不同的浏览器，并在企业管理的设置上工作。如果您没有为此做好计划，这就是通行密钥流程崩溃的地方。

### 4.1 生态系统碎片化是真实存在的

通行密钥生态系统跨越三大平台（Apple、Google 和 Microsoft）、多种浏览器（Chrome、Safari、Firefox 和 Edge）、数十个通行密钥提供商/凭证管理器（例如 1Password、Bitwarden、Dashlane 等等）以及无数的操作系统/浏览器/设备组合。每种组合的行为可能略有不同，例如：

- **Apple** 默认通过 iCloud 钥匙串在 iOS、iPadOS 和 macOS 之间同步通行密钥，但不向 Windows 或 Android 同步
- **Google** 通过 Google 密码管理器在 Android 和 Chrome 之间同步，但在 iOS 上的体验有所不同（您需要手动设置）
- **Windows** 有自己的通行密钥行为，与其他平台有显著差异
- **密码管理器**在处理通行密钥创建和选择方面各不相同，有时会与平台原生提示发生冲突

### 4.2 跨设备身份验证流程

当用户在他们的 iPhone 上创建了一个通行密钥，但想在 Windows 笔记本电脑上登录时，他们可以使用跨设备身份验证（通常通过二维码和蓝牙）。这个流程是可行的，但很脆弱：

- 它要求两台设备都启用蓝牙
- 由于后台会建立隧道，企业防火墙和 MDM 策略可能会产生干扰
- 不同浏览器之间的用户体验差异巨大
- 用户通常不明白发生了什么，或者为什么要扫描二维码

我们在数千种设备组合中亲眼见证了这些边缘情况。如果您在内部构建通行密钥，您需要测试并处理每一种情况。如果不能，您的用户就会遇到您的支持团队无法解释的错误。

### 4.3 浏览器和操作系统的诸多不一致

即使在同一台设备上，不同浏览器的行为也有所不同。macOS 上的 Chrome 显示的通行密钥模态框与 macOS 上的 Safari 不同。Firefox 也有自己的行为。客户端提示 (Client hints) 和用户代理 (User agent) 检测对于向正确的用户提供正确的流程变得至关重要，但在所有组合中正确解析它们是一项永无止境的维护负担。

## 5. 问题 3：原生应用成倍增加通行密钥的复杂性

对于 Web 应用而言，通行密钥的测试和 QA 本身已经是一个挑战（我们在[问题 5：平台更改](#7-issue-5-platform-changes-break-passkeys-silently)中详细介绍了这一点）。但如果您的产品还包含原生 iOS 和 Android 应用，那么由于架构决策和特定于平台的行为，其复杂性将会成倍增加，而纯 Web 团队则永远不会面临这些问题。

### 5.1 原生与 WebView 的抉择

第一个决定是通过原生方式还是通过 WebView 来实施通行密钥。每种方法都有权衡：

| 方面 | 原生实施 | WebView 实施 |
| ------------------------- | -------------------------------------- | ------------------------------------------ |
| **用户体验质量** | 一流的，原生平台体验 | 取决于 WebView 类型 |
| **维护** | iOS 和 Android 独立的代码库 | 共享 Web 逻辑 |
| **平台要求** | 必须遵循 Apple/Google SDK 的更改 | 必须处理 WebView 对通行密钥支持的问题 |
| **复杂性** | 高（特定于平台的 API） | 中等（但 WebView 类型很重要） |

单在 iOS 上，您就可以在 WKWebView、SFSafariViewController、SFAuthenticationSession 和 ASWebAuthenticationSession 之间进行选择——每种对通行密钥的支持特性都不同。在 Android 上，Chrome 自定义选项卡 (Custom Tabs) 的行为与标准的 WebView 不同。这些是纯 Web 团队永远不必做出的决定，而每个选择都会创造其自身的维护面。

### 5.2 原生应用中特定于平台的行为

除了架构决策之外，iOS 和 Android 在操作系统层面处理通行密钥的方式也有所不同：

- **iOS** 将通行密钥深度集成到系统凭证管理器中，具有特定的自动填充行为，这些行为可能会随着每个 iOS 版本的更新而变化
- **Android** 通过 Credential Manager API 路由通行密钥请求，该 API 可同时与多个通行密钥提供商交互
- 不同平台之间的错误状态、超时行为和用户提示也有所不同。即使用户取消操作，在 Web 端会显示为 `NotAllowedError`，但在 iOS 上会显示为 `SimpleAuthenticationServices.AuthorizationError`，而在 Android 的凭证管理器上则显示为 `User cancelled the operation`。
- 当您需要针对通行密钥的回归问题发布紧急修复时，应用商店的审核周期会造成延迟

### 5.3 增加了两倍的 QA 表面

如果您同时运营 Web 应用和原生应用，您的 QA 工作量不仅仅是翻倍，而是增加了两倍。Web、iOS 和 Android 各自都相当于独立的通行密钥环境，需要独立的端到端测试和监控。而且与 Web 端不同，您可以立即部署修复程序，原生应用的修复则受到应用商店审核周期的限制。

## 6. 问题 4：采用率是产品问题，而非技术问题

“支持通行密钥”并不意味着“使用通行密钥”。如果您没有推广策略和衡量指标，您的采用率将令人失望，该项目在内部将被标记为失败。

### 6.1 为什么低采用率会毁掉您的项目

我们在一篇关于通行密钥实施为何失败的文章中广泛探讨了这一点：如果用户不改用通行密钥，项目就已经失败了。密码仍然占据主导地位，SMS OTP 成本居高不下，网络钓鱼风险依然存在，您的组织也看不到重大工程投资的回报。

采用通行密钥的商业理由很充分，但这仅在采用真正发生时才成立。我们见过一些企业在上线通行密钥时技术实现非常出色，但采用率却不到 5%，因为没有人考虑过推广和采用策略。

### 6.2 采用率需要刻意的产品设计

推动通行密钥的采用是一项产品挑战，它需要：

- **渐进式注册**：在适当的时机（例如成功登录后、在帐户安全审查期间）引导用户创建通行密钥
- **清晰的用户沟通**：用非技术用户能够理解的语言，解释什么是通行密钥以及为什么它们更好
- **感知设备的提示**：仅在用户的设备真正良好支持通行密钥时才提供创建提示，避免在不支持的配置上造成令人沮丧的体验
- **衡量指标基础架构**：跟踪通行密钥的创建率、登录成功率、回退率和放弃率，以识别并修复瓶颈

### 6.3 什么是“优秀”的采用率

根据我们在大规模通行密钥部署方面的经验，以下是企业应设定的目标：

| 指标 | 较弱 | 可接受 | 强劲 |
| --------------------------------------------- | ------- | ---------- | ------- |
| **通行密钥创建率**（占符合条件的用户） | <10% | 10-60%     | >60% |
| **通行密钥登录率**（占所有登录） | <5%  | 5-40%      | >40% |

如果您的采用数字在三个月后看起来像“较弱”这一列，那么该项目就遇到麻烦了。如果没有数据分析来衡量这一点，您甚至不会知道。

## 7. 问题 5：平台更改会在暗中破坏通行密钥

操作系统和浏览器更新会更改提示、自动填充行为和回退流程。如果您没有持续的监控，您会在没有预警的情况下遭遇功能回归和支持工单。

### 7.1 为什么通行密钥独特地受平台更改影响

与密码（仅仅是服务器验证的字符串）不同，通行密钥依赖于与操作系统、浏览器和凭证管理器的深度集成。当 Apple 发布新的 iOS 版本时，通行密钥的创建提示可能会看起来不同。当 Chrome 更新其自动填充逻辑时，您的登录流程可能会被破坏。当密码管理器发布新版本时，它可能会开始以您意想不到的方式拦截通行密钥请求。

最近的一个例子是 iOS 26.2 的错误，该错误导致 `isUserVerifyingPlatformAuthenticatorAvailable()` 在所有非 Safari 浏览器（Chrome、Edge、Firefox）上均返回 `false`，这需要使用 `getClientCapabilities()` 作为变通方案来实现感知平台的检测逻辑。

### 7.2 监控是必选项

为了确保您能发现所有潜在的错误并跟踪采用情况，您需要建立您的身份验证可观测性技术栈。我们建议至少落实以下几点：

- **实时身份验证数据分析**：按操作系统、浏览器和通行密钥提供商组合跟踪成功和失败率
- **感知版本的监控**：检测新的操作系统或浏览器版本何时导致错误或回退激增。区分预期错误（用户中止操作显示的 `NotAllowedError`）和意外错误（由于并发错误导致 `AbortError` 激增，或者 Android 更新后出现的新的凭证管理器通行密钥错误）
- **告警**：在您的用户开始提交支持工单之前获得通知
- **快速响应能力**：能够快速推送修复程序或针对受影响的设备组合禁用通行密钥

这正是大多数团队在发生事故之前不会去构建的身份验证分析基础架构。到那时，对用户信任和内部项目可信度的损害已经造成。

### 7.3 持续的维护成本

通行密钥实施的真正成本不在于最初的构建，而在于持续的维护：

- 监控跨 iOS、Android、Windows、macOS 和所有主流浏览器的平台更改
- 测试每次更新是否存在回归
- 在浏览器 API 更改时更新您的前端 SDK
- 保持与不断增长的通行密钥提供商生态系统的兼容性
- 记录变更并传达给您的支持团队

## 8. 什么时候您（不）应该发布通行密钥

鉴于这些“第二天”问题，以下是对您何时应该以及何时不应该发布通行密钥的诚实评估。

### 8.1 不应该发布通行密钥，如果

- 您没有明确的回退和恢复策略
- 您没有跨用户实际使用的设备组合进行过测试
- 您有原生应用，但没有持续进行特定平台 QA 的计划
- 您没有分析基础架构来衡量采用情况
- 您无法投入工程资源进行持续维护
- 您纯粹是为了勾选合规复选框而实施通行密钥，却没有进行适当的规划

如果没有适当的规划，纯粹为了监管原因而孤注一掷可能会显著推高成本。实施不佳的通行密钥系统比没有通行密钥系统更糟糕：它会侵蚀用户信任，产生支持开销，并给内部利益相关者提供取消项目的理由。

### 8.2 应该发布通行密钥，如果

- 您已经为上述五个“第二天”问题做好了规划
- 您具备支持持续推广的产品、工程、安全和数据分析能力
- 您已为持续维护（而不仅仅是最初的构建）做好了预算
- 您有一个具有明确采用目标的阶段性推广策略
- 您正在与像 Corbado 这样的合作伙伴合作，由其为您处理运营的复杂性

### 8.3 自建与购买的决策

本文描述的“第二天”问题正是许多企业选择购买而不是自建其通行密钥基础架构的原因。构建 WebAuthn 服务器是最简单的部分。而在数千种设备组合中运行生产级通行密钥系统，并具备适当的恢复、监控和采用率分析功能，才是区分演示与真正部署的关键。

## 9. Corbado 如何解决通行密钥“第二天”问题

Corbado 的存在正是因为第二天的问题很难解决。我们的平台处理了运营的复杂性，因此您不必自己构建和维护。

### 9.1 恢复与回退

Corbado 提供开箱即用、具有自适应安全级别的恢复流程。从同步的通行密钥策略到跨设备身份验证，再到自动化的身份验证。恢复逻辑内置并持续更新。

### 9.2 跨设备兼容性

我们的前端 SDK 已在数千种操作系统、浏览器和通行密钥提供商组合中进行了预测试。设备检测、条件 UI (Conditional UI) 处理和回退路由会自动发生。当新版本的浏览器破坏了某些功能时，我们会在您的用户注意到之前在我们的 SDK 中对其进行修复。

### 9.3 原生应用支持

Corbado 支持原生和 WebView 的通行密钥实施，并通过 SDK 抽象化平台的差异。您只需专注于您应用的用户体验，而我们则处理跨 iOS 和 Android 的通行密钥底层工作。

### 9.4 采用率数据分析

我们的数据分析仪表板可跟踪所有重要的指标：通行密钥创建率、登录成功率、回退率以及设备级别的细分数据。您将获得可操作的见解以推动采用，而不仅仅是原始数据。

### 9.5 平台更改监控

Corbado 持续监控影响通行密钥的操作系统和浏览器更改。我们的 SDK 会主动更新。即使底层平台环境发生变化，您的通行密钥部署也能保持稳定。

## 10. 结论

通行密钥是身份验证的黄金标准。这是毫无疑问的。但是，从“支持通行密钥”到“让通行密钥大规模可靠地工作”的道路上铺满了大多数团队低估的“第二天”问题。

我们介绍的这五个问题（恢复、跨设备边缘情况、原生应用复杂性、采用率和平台更改）并不罕见。它们是任何生产级通行密钥部署的核心运营挑战。忽视它们并不能让它们消失，这只意味着您的用户会首先发现它们。

我诚恳的建议是：如果您没有相关的知识和资源来正确地实施通行密钥，就不要发布它们。要么对这些能力（产品、工程、安全和数据分析）进行投资，要么与已经解决这些问题的合作伙伴合作。最糟糕的结果是，由于没有人为第二天做好计划，部署了一个半成品的通行密钥系统，最终只能将其回滚。

## 常见问题解答

### 导致通行密钥项目在发布后失败的 5 个“第二天”问题是什么？

这五个运营问题是：不安全的恢复和回退流程、跨设备生态系统的边缘情况、原生应用的复杂性、低用户采用率以及操作系统和浏览器更新带来的静默回归。大多数团队将重点放在最初的 WebAuthn 集成上，而低估了这些发布后的挑战，这就是为什么许多通行密钥项目在内部被回滚或悄悄放弃的原因。

### 我该如何为在 iPhone 上注册了通行密钥但在 Windows 上使用的企业用户处理跨设备通行密钥身份验证？

用户可以通过二维码和蓝牙跨设备流程进行身份验证，但这需要两台设备都启用蓝牙，并且可能会被企业 MDM 策略和防火墙拦截。不同浏览器之间的用户体验差异显著，而且用户经常不明白为什么要扫描二维码，因此，具备感知设备的回退路由和清晰的沟通对于企业部署至关重要。

### 在发布后，我应该设定目标并跟踪哪些通行密钥采用指标？

强劲的采用率意味着通行密钥创建率超过符合条件用户的 60%，而通行密钥登录率超过所有登录的 40%。如果在三个月后，创建率低于 10% 且登录率低于 5%，则表明推广正在失败。要衡量这一点，需要专门的基础架构来跟踪创建率、登录成功率、回退率以及按设备和操作系统组合细分的放弃率。

### 我应该在我的移动应用中原生构建通行密钥，还是使用 WebView？

原生实施提供了一流的用户体验，但需要适用于 iOS 和 Android 的独立代码库，包括特定于平台的 API 处理和独立的 QA 流程。WebView 方法共享了 Web 逻辑，但会根据 WebView 类型引入通行密钥支持的不一致性。单在 iOS 上，在 WKWebView、SFSafariViewController 和 ASWebAuthenticationSession 之间的选择就带有不同的通行密钥支持特性，在致力于某个架构之前必须对此进行评估。

### 为什么通行密钥帐户恢复比看起来更难，正确的方法是什么？

简化的恢复（如基于电子邮件的重置）会重新引入容易被网络钓鱼攻击的渠道，而过于严格的恢复（如强制要求硬件安全密钥）则会导致用户放弃。推荐的方法是分层的：将同步的通行密钥作为主要策略，跨设备的二维码身份验证作为第二层，带有活体检测的自动化身份验证作为第三层，数字可验证凭证作为第四层。具体实施哪些层取决于您的威胁模型、用户群和监管要求。