---
url: 'https://www.corbado.com/zh/blog/passkeys-goumai-vs-zijian-zhinan'
title: '通行密钥购买与自建指南'
description: '购买还是自建通行密钥解决方案？探索自建通行密钥与通行密钥供应商解决方案（SaaS 和本地部署）的优缺点、挑战、成本及最佳实践。'
lang: 'zh'
author: 'Vincent Delitz'
date: '2025-07-15T09:19:14.760Z'
lastModified: '2026-05-28T06:05:38.734Z'
keywords: '自建通行密钥, 购买与自建通行密钥, 外包通行密钥, 通行密钥实施成本, 通行密钥成本比较, 通行密钥 SaaS 与自托管, 通行密钥供应商与内部开发, 通行密钥 ROI 分析, 实施通行密钥的挑战, 通行密钥实施最佳实践'
category: 'Passkeys Strategy'
---

# 通行密钥购买与自建指南

### 下载完整的《购买与自建通行密钥指南》

免费下载完整的\*\*《购买与自建通行密钥指南》\*\*，获取所有深度洞察。

- ✅ 响应阿迪达斯 (Adidas)、Woolworths 和三菱 (Mitsubishi) 等团队的需求
- ✅ 包含完整的构建模块列表和成本模型，帮助您在购买与自建之间做出决定
- ✅ 实用的 50 页决策框架

## Key Facts

- 对于大多数大规模的消费者部署而言，购买通行密钥供应商解决方案比内部自建能够提供更快的部署速度、更低的
  **TCO**（总拥有成本）以及更高的采用率。
- 在逐步淘汰密码之前，必须达到 50-80% 活跃用户的**关键采用阈值**，这使得采用工具成为决定自建还是购买的关键因素。
- 超过 27% 的密码登录会失败，而通行密钥身份验证可实现
  **95-97% 的成功率**，直接提升电子商务和零售业的转化率。
- 与“密码加短信 MFA”相比，通行密钥的速度提升了
  **3 到 5 倍**，这与更高的用户满意度和持续使用率息息相关。
- **开源 WebAuthn 库**提供了一个起点，但缺乏大规模部署所需的企业级安全性、优化的用户体验 (UX) 以及提升采用率的功能。

## 1. 动机：我应该购买还是自建通行密钥身份验证解决方案？

构建自己的通行密钥实现听起来很有吸引力：完全控制、自定义集成且不受供应商锁定。毕竟，[FIDO2](https://www.corbado.com/glossary/fido2)
是基于开放标准的，编写第一行 WebAuthn 代码似乎很容易。这到底能有多难？

但这往往正是复杂性开始的地方，特别是当您计划为以下行业中拥有数百万用户的大规模消费者部署场景构建解决方案时：

- **银行与金融服务**（例如在线、[银行](https://www.corbado.com/passkeys-for-banking)、[支付](https://www.corbado.com/zh/blog/shuzi-pingzheng-yu-zhifu)、金融科技）
- **政府与公共服务**（例如公民门户、税务和社保平台）
- **保险与医疗保健**（例如患者门户、数字[保险](https://www.corbado.com/passkeys-for-insurance)平台）
- **电子商务与零售**（例如[市场](https://www.corbado.com/passkeys-for-e-commerce)、忠诚度计划）
- **电信与公用事业**（例如移动运营商、[能源](https://www.corbado.com/passkeys-for-energy)供应商）
- **旅游与酒店**（例如[航空](https://www.corbado.com/passkeys-for-airlines)账户、酒店忠诚度计划）

真正的挑战始于首次成功的通行密钥登录之后，并且往往在您已经开始实施通行密钥解决方案时才显现出来。突然之间，诸如奇怪的边缘情况、令人困惑的用户错误以及由于通行密钥不可用导致潜在用户被锁定的问题接踵而至。原本看似简单的集成变成了数月甚至数年的开发工作、意外的维护成本以及一个可能失败的通行密钥项目。

然而，对于某些组织和特定需求，构建自己的解决方案也可能是正确的选择。我们已经与数十家组织讨论了他们的通行密钥实施计划，并亲身陪伴其中一些组织完成了这一旅程。本指南将帮助您确定何时采用 DIY（Do-It-Yourself）通行密钥方法可能是有意义的，以及何时选择成熟的通行密钥提供商是更明智的决定。

通过我们的\*\*《购买与自建通行密钥指南》\*\*，我们希望回答以下问题：

1. **实施通行密钥和实现无密码需要哪些组件？**
2. **我应该在内部实施通行密钥，还是使用外部通行密钥供应商？**
3. **在有开源库的情况下，使用通行密钥供应商有什么好处？**
4. **构建通行密钥解决方案最大的挑战是什么？**
5. **内部实施通行密钥的风险是什么？**

## 2. 先决条件：为什么通行密钥是登录的新标准

密码已过时、不安全且令人沮丧。通行密钥消除了网络钓鱼风险、改善了用户体验并简化了身份验证——使其成为安全登录的新标准。无论您是内部构建还是使用外部解决方案，集成通行密钥都是在安全性和可用性方面的重大升级。

Google 发现，以易用性或速度为卖点能够引起共鸣并发挥作用。人们普遍抱怨登录过程，因此任何能让这一过程变得更简单、更快速的措施都是一种胜利。

除了这些安全优势之外，通行密钥在节省运营成本方面也具有巨大潜力。您可以减少发送给用户的短信 OTP 数量，这对于庞大的用户群来说可能是一笔巨大的费用。此外，密码和 MFA 恢复给客户支持团队带来的负担也是一个可以消除的成本因素。

此外，通行密钥提高了用户的登录成功率并缩短了登录时间，最终带来了更好的转化率，这是推动[电子商务](https://www.corbado.com/passkeys-for-e-commerce)、[零售](https://www.corbado.com/passkeys-for-e-commerce)或[旅游](https://www.corbado.com/passkeys-for-travel)等行业顶线增长的主要驱动力。

![introducing passkeys table](https://www.corbado.com/website-assets/introducing_passkeys_table_b5fd537984.jpg)

## 3. 无密码之旅：通行密钥如何发挥作用？

![passwordless-journey-passkeys.png](https://www.corbado.com/website-assets/passwordless_journey_passkeys_af666bc198.png)

许多考虑引入通行密钥的组织的最终目标是实现完全无密码。为了实现这一目标，通常需要完成四个阶段。这些阶段进展的速度在很大程度上取决于组织的技术能力、登录模式和用户群。在某些情况下，外部因素（例如公众要求引入更安全的身份验证的压力或财务限制）也可能发挥作用。

让我们逐步了解并描述这四个阶段，因为实施通行密钥只是确保通行密钥项目成功的一步。

### 3.1 阶段 1：集成通行密钥

向完全无密码系统过渡的第一步是**将通行密钥集成为一种登录方法**。在此阶段，密码和其他身份验证方法仍作为后备保留，以确保尚未采用通行密钥的用户仍然可以访问其帐户。成功的集成需要与现有登录流程和安全策略无缝兼容。组织应专注于使通行密钥的创建变得简单直接，确保技术和非技术用户都能毫无摩擦地采用这种新的身份验证方法。

### 3.2 阶段 2：提高通行密钥采用率

集成通行密钥后，下一个挑战是**推动用户采用通行密钥**。许多组织低估了这一阶段的重要性，但如果没有广泛的用户采用，通行密钥项目很可能会失败。目标是鼓励尽可能多的用户创建和使用通行密钥，理想情况下使其成为默认登录方法。

提高采用率的关键策略包括主动的用户教育、促进通行密钥创建的 UI 提示，以及奖励用户转换的激励计划。组织应设定一个关键采用阈值，例如 50-80% 的活跃用户利用通行密钥，然后再进入下一阶段。要更深入地了解为什么采用率至关重要，请参阅我们[关于糟糕采用率如何危及通行密钥项目的专门文章](https://corbado.com/blog/why-passkey-implementations-fail)。

### 3.3 阶段 3：移除密码

随着通行密钥采用率达到临界数量，组织可以**开始逐步淘汰密码**。然而，过早移除密码或没有仔细计划可能会导致可用性问题并增加支持请求。建议采用分阶段的方法：

- 从用户一致通过通行密钥进行身份验证的帐户开始移除密码。
- 在帐户设置中为早期采用者提供移除密码的选项。
- 使用数据驱动的洞察力来识别已准备好完全无密码的用户。例如，可以优先考虑在不同设备上注册了多个通行密钥的用户。
- 主动传达移除密码的好处，以建立用户信心。

通过有策略地引导用户实现完全无密码身份验证，组织可以在不破坏用户体验的情况下最大限度地提高安全性。

### 3.4 阶段 4：自动化帐户恢复

一旦移除密码，帐户恢复机制必须稳健且安全。传统的恢复方法通常依赖于手动干预，例如支持工单或电子邮件重置，这可能会引入安全风险和运营成本。组织必须实施**现代、自助的帐户恢复**解决方案，在提高用户体验的同时保持安全性。

自动化帐户恢复的关键要素包括：

- **活体检测**：通过确保用户在场来防止未经授权的帐户接管。
- **ID 验证**：利用[政府](https://www.corbado.com/passkeys-for-public-sector)颁发的 ID 和生物识别验证来确认身份。
- **后备通行密钥**：允许用户使用存储在其其他设备上的备份通行密钥恢复帐户。

许多组织在过渡到无密码之余，已独立投资于自动化恢复流程，以降低成本并增强可用性。然而，在以通行密钥驱动的生态系统中，这些机制对于维护安全性和减少摩擦变得更加关键。

基于这四个阶段，我们现在将尝试帮助您评估购买与自建的决定。因此，对于**通行密钥项目的长期成功而言，牢记所有阶段**而不仅仅是集成通行密钥是非常重要的（这仍然可以作为一个目标，但那样您就会浪费掉通行密钥的全部潜力）。

![account recovery](https://www.corbado.com/website-assets/account_recovery_45773684fd.png)

## 4. 如何确定正确的通行密钥方法

在 DIY 和外部通行密钥解决方案之间做出选择，取决于您公司的技术资源、安全优先级、部署规模以及长期的通行密钥策略。在下一节中，我们将分解关键方面以帮助您做出最佳决定。

下表显示了您需要评估的不同评估标准。根据您更倾向于哪种陈述，会提供不同的分数。

**如何使用评估矩阵：**

对于每个标准，选择贵公司需要更简单还是更复杂的解决方案。

- 对于最符合左侧描述且复杂性在您的情况中最低的每个答案，分配 **1 分**。
- 对于更符合右侧最高复杂性描述的每个答案，在**该类别中**分配 **5 分**。
- 如果您不确定，请使用 **3 分**作为中性选项。

### 下载完整的《购买与自建通行密钥指南》

免费下载完整的\*\*《购买与自建通行密钥指南》\*\*，获取所有评估标准。

## 5. 如何有效使用本指南

在决定是自建还是购买通行密钥解决方案时，重要的是着眼于整个过程，而不仅仅是通行密钥推出的单个阶段。即使您近期的首要任务是提供通行密钥作为 MVP（最小可行产品），您也应该预测长期的影响，特别是**推动采用**。以下是我们建议如何使用本指南和解释您的结果，并强调为什么采用比几乎任何其他因素都更重要。

### 5.1 将采用作为第一大成功因素

无论您的通行密钥解决方案多么先进，**如果用户不通过创建通行密钥和使用通行密钥登录来采用它，整个项目就会面临风险**。根据我们的经验，组织往往低估了促使用户放弃密码所需的工作量。即使您在技术层面上无缝地实施了通行密钥，低采用率也会导致：

- **持续依赖密码**，从而抵消了通行密钥的安全优势。
- **投资回报率 (ROI) 极低**，因为节省的成本（更少的密码重置，减少的短信 OTP）取决于大量使用通行密钥登录。
- **割裂的用户体验**，如果大多数登录仍通过传统方法进行，而只有一小部分用户使用通行密钥。

在您能够朝着减少或完全消除密码迈出有意义的一步之前，通常需要**您的用户群达到较高的采用率（有时为 50% 甚至超过 80%）**。像 Google 和 Amazon 这样的组织设定了明确的采用目标，并系统地运行 A/B 测试、用户教育活动和 UI 提示，以确保通行密钥被广泛接受。这种对采用的集中努力不是可有可无的；这正是将您的通行密钥部署从一项功能转变为切实竞争优势的关键。

### 5.2 全面或分阶段使用指南

本指南旨在帮助您在过程的每个阶段就通行密钥实施做出明智的决定：

1. **阶段 1（集成通行密钥）：**
   如果您只是考虑是否采用通行密钥以及如何集成它们，请关注通行密钥集成的\_自建与购买\_标准。
2. **阶段 2（提高采用率）：**
   如果您希望通行密钥不仅仅是一个功能，请尽早计划以推动用户采用——即使对于
   [MVP](https://www.upsilonit.com/blog/ai-mvp-development-a-basic-guide)
   而言，因为这需要额外的技术投资，通常远远超过初始实施成本。
3. **阶段 3（移除密码）：**
   如果消除密码是一项长期的战略目标，请确保您的架构和用户流程在设计时考虑到这最终的一步。
4. **阶段 4（自动化帐户恢复）：**
   即使您今天还没有准备好完全无密码，也要确保您的通行密钥方法可以演变成强大、无缝的恢复机制，以避免未来的路障。

其中，**阶段 2（提高采用率）是最重要的**。您可以分别评估每个部分，但请记住，您的长期成功和 ROI 通常取决于您从一开始对采用率的重视程度。

### 5.3 涉及主要利益相关者并在采用目标上保持一致

如果您正处于决定实施通行密钥的早期阶段，请从评估矩阵的第一部分（通行密钥集成）开始，并与管理层、IT、产品所有者和其他关键决策者一起填写。问问你们自己：

1. **我们期望的通行密钥登录率是多少？**
   5% 就足以证明可行性，还是我们需要 50–80% 才能认为通行密钥取得了成功？
2. **我们是否有预算和高管层的支持**来进行长达数月的 A/B 测试、开展优化活动、创建教育材料并不断完善用户流程，从而让用户理解并愿意转用通行密钥？是否有足够的工程能力来实施所有必要的报告、分析和测试？我们发布的频率是否足以实现这些目标？
3. **长期愿景是什么？** 我们的目标是消除密码，还是仅仅提供一种替代方案？

预先回答这些问题可确保您的通行密钥项目不会走入死胡同。未能为采用做出计划的组织通常会发现自己在未来几年内仍然被密码所困，从而削弱了整体安全性和用户体验策略。

### 5.4 离“中性”越远，供应商越有意义

在整个矩阵中，每个评估标准都能让您处于**最低复杂性 (1)** 到**最高复杂性 (5)**
之间的任何位置。您的答案越多地转向甚至超越中性区域
**(3)**，使用专门的通行密钥供应商的理由就越充分：

- **高复杂性要求**——例如高级后备方法、严格的合规性、深度分析和多设备 UX——成倍地增加了您的工程和维护负担。
- **强烈强调采用**——要快速实现高通行密钥采用率或消除密码，通常需要经过充分测试的用户流程、详细的遥测数据和结构化的提示。

这些因素在技术和组织上都可能使内部团队不堪重负。托管的通行密钥解决方案通常能够提供经过验证的最佳实践、快速更新以及现实世界的专业知识，从而比 DIY 方法更快地提高采用率。

### 5.5. Corbado 的观点：什么时候供应商是更好的选择

作为通行密钥专家，我们在 **Corbado**
拥有强烈的观点。如果通行密钥在您的路线图中，并且您想要一个**最先进的实现**来**积极推动采用**，Corbado
Connect 可以帮助您大规模解决复杂性问题。原因如下：

![product related outcome](https://www.corbado.com/website-assets/product_related_outcome_23dde860af.jpg)

**采用已内置于解决方案中：**
我们的平台旨在通过智能提示、分析和持续的 A/B 测试来最大限度地提高用户参与度，这同时也能节省成本。

后续步骤：

1. **填写评估矩阵的每个相关部分**——考虑近期和长期的目标。
2. **在您的决策中优先考虑采用**——与利益相关者就明确的采用目标和实现这些目标的资源保持一致。
3. **一旦您了解了复杂性和采用目标，请比较内部和供应商解决方案的 TCO**，并完成内部流程以评估是自建还是购买。

![internal stakeholder goals](https://www.corbado.com/website-assets/internal_stakeholder_goals_6c4e605c9d.jpg)

4. 如果您的战略目标指向一个能够有效处理技术和采用挑战的全托管平台，请**咨询通行密钥专家**（如 Corbado）。

通过以全面的方式解决通行密钥问题并将采用作为关键目标之一，您将获得最佳结果。这意味着更强的安全性、更简单的登录以及通向无密码未来的真正途径。如果您有兴趣了解有关
**Corbado Connect**
的更多信息以及我们如何帮助客户实现高通行密钥采用率，我们随时可以进行沟通。

## 6. 如何衡量通行密钥部署的成功？

现在，我们已帮助您确定了回答“购买还是自建？”问题的正确方法，我们将分析如何评估通行密钥部署的成功。因此，我们定义了通行密钥项目的输入和输出 KPI。

![why passkey adoption matters](https://www.corbado.com/website-assets/why_passkey_adoption_matters_7f0a3b0413.png)

### 6.1 什么是重要的通行密钥输入 KPI？

输入 KPI 有助于跟踪通行密钥的**早期采用情况**，以及是否已建立广泛使用的必要条件。这些指标先于实际登录行为，但对于实现有意义的采用和优化部署至关重要。

| **KPI**                  | **定义**                                                                                                                                                                                                                                                                                                                                                                                                                            | **为何重要**                                                                                           | **如何衡量**                                                                                                                   | **基准**                                                                                               |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| **通行密钥接受率**       | 在成功登录（登录后）之后，收到“提示”（鼓励他们设置通行密钥的通知或建议）并选择创建通行密钥的用户百分比。此 KPI 专门衡量用户对这些登录后提示的响应情况，突出了提示消息在推动通行密钥创建方面的有效性。这种方法被认为是最先进的，因为用户通常不会通过帐户或凭据管理设置主动创建通行密钥。相反，在用户登录后直接提示时，最成功地采用了通行密钥，使提示成为创建通行密钥的主要驱动力。请确保区分第一次提示和随后的提示，因为比率会下降。 | 高接受率表明成功的用户说服和提示设计。低接受率表明存在摩擦、消息不清晰或用户犹豫不决。                 | **公式**：（在提示后完成通行密钥创建的用户数）÷（暴露于提示的用户数）。按操作系统/浏览器/设备进行细分。                        | 第一次提示时为 50%-75%，在移动设备上经过多次提示最高可达 85%。在桌面上较低。严重取决于措辞和实现方式。 |
| **通行密钥创建成功率**   | 开始通行密钥注册流程但**成功完成**它（即未放弃）的用户的比例。                                                                                                                                                                                                                                                                                                                                                                      | 显示有多少用户因令人困惑的用户体验、技术问题或用户的重新考虑而在创建中途\_放弃\_。                     | **公式**：（成功完成注册通行密钥的次数）÷（注册尝试次数）按操作系统/浏览器/设备分析失败点。                                    | 接近 100%。                                                                                            |
| **已创建的通行密钥数量** | 在给定期间（每天、每周、每月）内新创建的通行密钥的累计计数。                                                                                                                                                                                                                                                                                                                                                                        | 一种原始的采用指标，通常被视为半输出 KPI。反映了通行密钥使用的**量级**以及未来可能摆脱密码的登录转变。 | **公式**：按操作系统、浏览器、设备类别新注册的通行密钥总和。监控随时间的增长趋势。绝对数量没有必然意义，它取决于用户群的规模。 | 一旦全面推出，每天都有相当大的数量。                                                                   |

这些**输入 KPI**
可作为未来通行密钥采用情况的领先指标，并允许组织微调用户教育、UX 流程和技术实施。

### 6.2 什么是重要的通行密钥输出 KPI / OKR？

输出 KPI
(OKR) 通过评估用户行为、运营改进和业务影响来衡量通行密钥采用的实际成功程度。这些指标反映了通行密钥部署在现实世界中的有效性。通行密钥登录率是一项核心输出 KPI，因为它直接反映了实际的通行密钥采用和使用情况。不断上升的通行密钥登录率表明成功入职，以及用户继续偏好通行密钥而不是传统身份验证方法。

| **KPI**                            | **定义**                                                                                                           | **为何重要**                                                                                                                                                                                                                               | **如何衡量**                                                                                                                                                                                      | **基准**                                                                                                     |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **用户激活率**                     | 在所有至少看过\_一次\_提示（随着时间的推移可能是多次提示）的用户中，最终创建了**至少一个通行密钥**的用户的百分比。 | 衡量经过多次提示后通行密钥入职的\_整体\_成功率。用户可能会拒绝第一次提示但在稍后转换。                                                                                                                                                     | **公式**：（已创建≥1个通行密钥的唯一用户数）÷（至少显示过一次提示的唯一用户数）按操作系统、浏览器、设备进行细分，以了解谁最终采用了通行密钥。一旦部署规模扩大，已删除的通行密钥也必须在此处反映。 | 在 12 个月内超过 50%。通行密钥登录率趋向于用户激活率。这将取决于您用户的构成。                               |
| **通行密钥登录率**                 | 使用通行密钥而不是传统方法（密码、短信 OTP 等）完成的\_所有\_登录事件的百分比。                                    | 展示现实世界中通行密钥使用的频率。如果登录率一直较低，则表明用户尽管最初创建了通行密钥，但仍偏好或重新使用密码，反映了激活率低（因为只有在激活本身很高的情况下才会出现高登录率），或者是因为没有自动利用现有通行密钥的次优登录实施导致的。 | **公式**：（通行密钥登录次数）÷（总登录次数）按操作系统/浏览器/设备或用户组细分。这有助于定位通行密钥使用率低的问题平台或人口统计群体。                                                           | 数周内超过 20%，12 个月内超过 50%。（在很大程度上取决于您的实现方式）                                        |
| **通行密钥登录成功率**             | 通行密钥登录尝试以成功结束且未退回到备用方法的比例。                                                               | 揭示了通行密钥流程中的摩擦。较低的费率可能表明用户困惑、环境限制或导致回退的设备兼容性问题。由于用户切换设备或尝试从尚未连接的设备登录，因此预计不会达到 100%。高度取决于用户模式和使用的设备。                                            | **公式**：（成功的通行密钥登录次数）÷（尝试的通行密钥登录次数）跟踪部分尝试，即用户在中途放弃通行密钥并切换到密码。                                                                               | 在移动网络上超过 95%。在原生应用上超过 99%。桌面登录率取决于有多少用户拥有多台设备，以及他们首先在哪里注册。 |
| **通行密钥登录时间与传统登录时间** | 比较通过通行密钥与密码（或其他传统方法）进行身份验证的平均时间（从用户启动登录到成功完成的这段时间）。             | 更快的通行密钥登录时间与更高的用户满意度和持续使用率息息相关。                                                                                                                                                                             | 记录每次登录尝试的开始和成功时间戳。计算平均通行密钥登录时间与平均传统登录时间。按操作系统/浏览器/设备进行细分以获取更深入的洞察力。                                                              | 速度提升 3 到 5 倍。当与现有的 MFA（密码+短信）比较时。                                                      |
| **回退率**                         | 用户在最初以通行密钥开始的登录尝试中退回到密码或其他非通行密钥方法的频率。                                         | 显示了对传统流程的持续依赖，可能是由于通行密钥可靠性差或用户不习惯。                                                                                                                                                                       | **公式**：（回退事件次数）÷（通行密钥登录尝试次数）将回退数据与用户调查或支持工单关联以确定根本原因。                                                                                             | 该 KPI 基本上是倒置的通行密钥登录率，并取决于您的实施情况。                                                  |

最主要的是优化通行密钥登录成功和通行密钥登录率，以确保无摩擦的用户体验，同时努力提高用户激活率——但这仅在登录成功率足够高，以避免引入用户挫败感时。此外，按不同细分（如操作系统、浏览器和设备）和特定用例（例如跨设备登录）跟踪这些 KPI，可以更深入地了解采用模式和潜在的摩擦点。

### 6.3 如何记录通行密钥指标的必要事件

为了准确衡量输入 KPI（例如接受度、创建）和输出 KPI（例如登录率、后备使用），需要从三个主要来源收集数据：

1. **前端事件数据**
2. **通行密钥/凭据存储**
3. **传统身份验证和回退日志**

#### 6.3.1 前端事件数据

要计算**通行密钥接受率**或**通行密钥创建成功率**等指标，您必须检测有多少用户看到登录后提示，有多少用户点击“是的，创建通行密钥”，以及他们是否真正完成了通行密钥创建。这要求使用 JavaScript（或原生移动端）事件跟踪来捕获：

- 何时及是否显示提示（第一次与后续次数）
- 他们完成提示需要多长时间
- 他们是否中止了一次或多次通行密钥创建过程

您还需要**用户代理解析**或**客户端提示**，以将接受率与特定的操作系统/浏览器版本联系起来，从而能够检测特定损坏的路径。

#### 6.3.2 通行密钥/凭据存储

在用户在前端启动注册后，服务器必须确认是否真正存储了新的通行密钥。您需要访问数据库或外部身份提供商的 API 来记录每个凭据的创建事件。该存储库有助于计算每个用户存在的通行密钥数量，并跟踪最终结果（成功或失败），从而确保您确切地知道哪些尝试以完成注册告终。

#### 6.3.3 传统身份验证和回退日志

对于**回退率**等指标，您必须查看当前的身份验证日志和流程。通过将这些日志与前端事件统一起来，您可以了解用户是否开始了通行密钥登录、出现错误并切换到后备登录（如短信或密码）。

最后，衡量基于时间的 KPI，如**通行密钥登录时间与传统登录时间**，依赖于客户端和服务器的时间戳。因为许多组织只记录成功的登录，您必须为部分或失败的通行密钥流添加仪表盘监控，才能真正评估摩擦和回退。综合这三个数据源，同时兼顾隐私和监管限制，通常比预期要复杂得多，这也是导致一些团队采用专门的通行密钥平台（提供内置分析和事件跟踪）的另一个因素。

#### 6.3.4 Corbado 的集成方法：身份验证过程挖掘

Corbado
Connect 组件通过为启动身份验证过程的每个用户自动生成独特的流程，隐式地收集所有描述的数据点（数以百计的不同数据点）。通过无缝集成，**Corbado 还能从您现有的解决方案中收集身份验证指标**。这种全面的视图精确地指出了针对用户的改进点，提供对所有关键通行密钥 KPI 的全面见解，无需您付出额外努力。

### 6.4 哪些是应该受到影响的其他重要的输出 KPI / OKR？

此外，成功部署通行密钥后也应出现以下输出 KPI 效果，并且在企业内部大多已经进行了收集：

**运营和成本降低指标**

- **短信 OTP 使用量的减少** – 因通行密钥身份验证而节省的短信 OTP 数量（直接成本节省）。
- **密码重置请求的减少** – 与忘记密码相关的技术支持帮助台交互次数的减少。
- **客户支持工单的减少** – 与身份验证相关的客户服务问题的数量下降。
- **支持呼叫量的减少** – 与账户访问问题相关的呼入电话的减少。

**业务和用户体验影响指标**

- **用户保留率** – 用户在首次登录后继续身份验证的百分比。
- **转化率** – 用户在身份验证后完成交易的频率。
- **登录漏斗中的流失率** – 通行密钥是否减少了放弃登录尝试的用户数量。

[Watch on YouTube](https://www.youtube.com/watch?v=wnrXJzvBjsU)

通过专门跟踪通行密钥的输入和输出 KPI，并将它们与其他数据相关联，组织可以量化其通行密钥部署的影响，并进行由数据驱动的改进，以最大限度地提高采用率、降低成本并增强安全性。

## 7. 建议

选择合适的**通行密钥解决方案**取决于**您的具体挑战、安全需求和成本考虑**。以下是针对各个行业进行**购买与自建决策**的关键建议。

### 7.1 银行和金融服务领域的通行密钥建议

**关键考虑因素：**

- 监管合规（例如
  [PSD2](https://www.corbado.com/blog/psd2-passkeys)、[SOC 2](https://www.corbado.com/blog/cybersecurity-frameworks)、[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks)、GDPR）要求在通行密钥身份验证中采取严格的安全措施。
- 通行密钥成本的比较至关重要，因为银行通常低估了内部解决方案在长期复杂性和维护方面的问题。
- 安全认证是减少账户接管欺诈和网络钓鱼的关键。

**建议：**\
多数银行和金融机构应依赖于通行密钥供应商的解决方案，而不是在内部构建，因为在内部管理通行密钥基础设施带来的潜在复杂性超过了传统 IT 专业知识所能应对的范围。大规模实施通行密钥身份验证需要不断进行优化和更新、管理 WebAuthn 的兼容性，以及与现有的[银行](https://www.corbado.com/passkeys-for-banking)系统无缝集成——所有这些都是通行密钥供应商已经在持续做的事情。

像 Ubank、[Revolut](https://www.corbado.com/blog/revolut-passkeys) 和 [Finom](https://www.corbado.com/blog/finom-passkeys)
这样的银行正在引领通行密钥的使用，认识到了这项技术在增强安全性和改善用户体验方面的潜力。通行密钥 ROI（投资回报率）的分析通常倾向于购买解决方案而非在持续的维护和更新上进行投资，实际部署结果表明欺诈尝试和与身份验证相关的支持成本出现了显著下降。

**示例：** Armstrong Bank、First Financial
Bank、Ubank、[Revolut](https://www.corbado.com/blog/revolut-passkeys)、[Finom](https://www.corbado.com/blog/finom-passkeys)、Neobank、Cathay
Financial Holdings、Stripe、[PayPal](https://www.corbado.com/blog/paypal-passkeys)、Square

### 7.2 医疗保健领域的通行密钥建议

**关键考虑因素：**

- HIPAA 和 GDPR 的合规要求在采用通行密钥时采取严格的身份验证安全保障。
- 实施通行密钥的挑战在于在患者、医护人员和医院 IT 管理员之间兼顾安全性与易用性。
- 许多[医疗保健](https://www.corbado.com/passkeys-for-healthcare)的身份验证系统仍依赖于旧的基础设施，使通行密钥集成更为复杂。

**建议：**\
通行密钥供应商解决方案是满足合规要求且同时简化身份验证的最有效途径。供应商负责安全补丁、合规更新以及身份验证的可靠性，减轻了 IT 团队的负担。

**示例：** CVS Health、Caremark、Helsana、NHS、Swica

### 7.3 电子商务与零售领域的通行密钥建议

**关键考虑因素：**

- 转化率优化 (CRO) 对业务至关重要——身份验证时的摩擦直接影响收入。
- 多设备场景必须无缝运行（用户在移动设备上浏览，在桌面设备上完成结账）。
- 身份验证错误直接增加购物车弃单率，使得针对 UX 优化的登录流程变得必不可少。

**建议：**\
[电子商务](https://www.corbado.com/passkeys-for-e-commerce)平台可从能够提供高采用率的通行密钥实施提供商那里获得最大利益。像亚马逊 (Amazon) 和 [Shopify](https://www.corbado.com/blog/shopify-passkeys)
这样的大型平台已实施了通行密钥身份验证，表明该技术在[电子商务](https://www.corbado.com/passkeys-for-e-commerce)领域的应用日益增长。现实世界中的数据表明，最初由于密码登录失败的情况超过 27%，而基于通行密钥的身份验证成功率可以达到 95-97%，正如[过往的采用案例](https://fidoalliance.org/case-study-intuits-roi-from-passwordless-customer-authentication/)所示。通行密钥投资回报率分析表明，更高的转化率和更低的欺诈损失迅速证明了这笔投资是合理的。

亚马逊最近表示，他们设定了一个雄心勃勃的目标，即实现 100% 的通行密钥采用率以及彻底消除密码。

Google 也发现，使用通行密钥互动的试用用户向付费用户的转化率，比没有使用的用户高 20%。

**示例：** [KAYAK](https://www.corbado.com/blog/kayak-passkeys)、Amazon、Mercari、Best
Buy、[eBay](https://www.corbado.com/blog/ebay-passkeys)、Home Depot、[Shopify](https://www.corbado.com/blog/shopify-passkeys)、Target

### 7.4 旅游与酒店领域的通行密钥建议

**关键考虑因素：**

- 跨设备身份验证必不可少，因为用户在一台设备上预订行程，并在另一台设备上办理登机或入住。
- 专业的通行密钥供应商必须保障快捷安全的登录，以便提供便利的预订、登记及账户管理功能。
- 欺诈预防是优先事项，因为[旅游](https://www.corbado.com/passkeys-for-travel)平台处理高价值交易。

**建议：**\
大多数[旅游](https://www.corbado.com/passkeys-for-travel)公司应实施通行密钥解决方案，以增强安全性和用户体验。像 [Kayak](https://www.corbado.com/blog/kayak-passkeys)
和大型[航空公司](https://www.corbado.com/passkeys-for-airlines)这样的领先公司已经开始利用通行密钥身份验证来改善用户体验。预先构建的解决方案可提供更强的欺诈检测、无缝登录体验，以及即时的多设备支持。酒店行业尤其实益于入住时间的缩短和实施通行密钥提升的安全保障，能够确保所有接触点（应用程序、终端自助机、网页及合作平台）实现顺畅的身份验证。

**示例：** Air New Zealand、Bolt、Grab、[Uber](https://www.corbado.com/blog/uber-passkeys)、Hyatt

### 7.5 保险领域的通行密钥建议

**关键考虑因素：**

- 实施通行密钥的成本必须与合规性需求及用户体验改善保持一致。
- 许多[保险](https://www.corbado.com/passkeys-for-insurance)客户并非特别精通技术，因此必须保障在各种设备和浏览器上的出色用户体验。
- 处理保单管理和索赔通常需要集成通行密钥和身份验证。

**建议：**\
外部通行密钥解决方案最适合快速部署并满足监管要求。[保险](https://www.corbado.com/passkeys-for-insurance)提供商表示，在实施通行密钥后，与身份验证相关的支持工单大幅减少。提供定制身份验证流程及集成身份验证的通行密钥提供商能够确保安全，同时保持客户登录的简便性。分析表明，通行密钥降低了密码重置需求和欺诈损失，可抵消供应商成本。

**示例：** Branch

### 7.6 政府及公共服务领域的通行密钥建议

**关键考虑因素：**

- 具备最高的安全标准和合规要求（例如 [NIST](https://www.corbado.com/blog/nist-passkeys)，以及 Essential
  Eight 框架要求的抗网络钓鱼 MFA）。
- 需要针对有着不同技术熟练程度差异的大量用户群进行大规模部署。
- 需要将[政府](https://www.corbado.com/passkeys-for-public-sector)身份认证系统及遗留基础设施进行集成。

**建议：**\
对于[政府](https://www.corbado.com/passkeys-for-public-sector)机构，能够满足严格安全标准并保障无障碍使用的专用通行密钥解决方案不可或缺。[VicRoads](https://www.corbado.com/blog/vicroads-passkeys) 的成功实施证明了，政府组织在使用能够自动处理合规需求及安全更新的外部解决方案时会获益最大。因此，请选择能够提供企业级安全功能、支持多设备身份验证并具有自适应身份验证流程以适应所有公民需求的实施提供商。

**示例：** [VicRoads](https://www.corbado.com/blog/vicroads-passkeys)、myGov、State of Michigan

### 7.7 电信及公用事业领域的通行密钥建议

**关键考虑因素：**

- 可扩展性和可靠性十分关键，因为[电信](https://www.corbado.com/passkeys-for-telecom)及公用事业的提供商常常需要管理数百万涉及不同客户群体的用户，因此需要高可用性及容错的身份验证机制。
- 必须具备多设备和跨平台支持能力，因为用户通过移动应用程序或网页端口访问账户。无缝连接的通行密钥身份验证须覆盖所有的客户接触点。
- 支持传统的身份验证系统常是不可或缺的，因为提供[电信](https://www.corbado.com/passkeys-for-telecom)和公用事业的机构可能需要在现有的 IAM 系统及客户身份平台中集成通行密钥，且不能中断目前的身份验证流程。
- 防止诈骗及保障账户安全是最高优先级目标，特别是在针对 SIM 卡互换欺诈、身份盗窃和未经授权的账户访问方面。通行密钥可以大幅降低网络钓鱼攻击和凭证填充的风险。

**建议：**\
对于[电信](https://www.corbado.com/passkeys-for-telecom)及公用事业公司，推荐采用外部的通行密钥解决方案。鉴于这些行业的体量、复杂程度以及安全性需要，一个能够负责管理通行密钥业务的供应商可保证合规、高度可用，并实现与现有的身份验证基建实现无缝集成。许多电信巨头及公用事业行业领军公司已将通行密钥纳入其自身的安全升级流程，以期降低欺诈并改善用户体验。同时，由于需要把后续的维护更新及管理工作转交给供应商处理，购买实施解决方案相较于内部的开发将降低总体拥有成本 (TCO)。

**示例：** Deutsche Telekom、[Telstra](https://www.corbado.com/blog/telstra-passkeys)、SK
[Telecom](https://www.corbado.com/passkeys-for-telecom)

### 7.8 B2B SaaS 领域的通行密钥建议

**关键考虑因素：**

- 在 B2B SaaS 中必须进行多租户身份验证，要求实现具有跨不同 IAM 系统拓展的通行密钥集成。
- 企业期待使用 [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) (OIDC/SAML)，所以与 Identity
  Providers 进行无缝集成是直接关系到商业成果的重点。
- 需权衡通行密钥与 MFA 和零信任安全等其他方面的安全投资实施成本。

**建议：**\
对外购买实施方案对大多数 B2B SaaS 供应商而言，是不二之选。它往往比内部的开发部署来得更快捷。Notion，Hubspot 或
[Vercel](https://www.corbado.com/blog/vercel-passkeys)
这类的电子 B2B 公司均已使用通行密钥来强化身份验证安全性。由于服务提供方将承担后期管理，更新升级及满足需求，它降低的总成本 (TCO) 也是极具优势的。

**示例：** Canva、DocuSign、Notion

## 8. 结论

通行密钥已经成为在身份验证领域的全球标准了，为终端客户把关了更为便捷又加注了安全筹码的登入。在公司正考虑衡量应如何开展实施时，应当理清是该内部独立开发完成，还是依靠专业的通行密钥供应商。开发团队亲自处理虽然掌控度较高，却依赖雄厚的技术支撑开发环境并伴随后续常态的维系。反之，供应商为该事项提供了快速，且能拓展和具有本益比高成效的方式，保障能够大范围采纳应用、体验无摩擦且与正在优化的安全准则兼容的体验，

本指南重点回应了以下问题：

- **实施通行密钥和实现无密码需要哪些组件？**

    在成功的部署通行密钥前须配妥
    [FIDO2](https://www.corbado.com/glossary/fido2)/WebAuthn 基建设施并保障流畅丝滑的体验与备位处理措施并设立保障安全账户还原的选择机制。公司还须评估在面对不同平台进行兼容性上的衡量并进行在数据安全方面的把关。

- **我应该在内部实施通行密钥，还是使用外部通行密钥供应商？**

    尽管选择使用自身开发可以在一定程度上达成统筹管控但在无形中也引入了棘手的情境与伴随而来的后援工作。因此绝大数受众体量较大的商业导向团队采用由通行密钥供应商完成部署会获得如减少在技术面的冗员安排以及更快的起效。

- **在有开源库的情况下，使用通行密钥供应商有什么好处？**

    开源 WebAuthn 库充其量是个基本组件但在面对企业规模的安全机制把关和提高优良的产品感受以增进接受程度上，却是相形见绌的。在通行密钥专业供应商手中能将之发扬和推广并能够增加 ROI 回报的成果，也因此省却开发和推广方因不顺遂而带来的痛感。

- **构建通行密钥解决方案最大的挑战是什么？**

    构建一个开发自用的通行密钥体制，对 WebAuthn 要有着深入骨髓的研究，以及支持各类兼容硬件和对通行密钥认可的环境。在多环境设备上支持通行并致力于提供长效服务无形中都将使整个过程充斥挑战。

- **内部实施通行密钥的风险是什么？**

    企业可能会在不觉间掉进无止境和旷日废时的进程并要为了保障和支持各种维护买单。不符相关条款所引发失败和薄弱的信息漏洞加上低靡的使用将造成失败。通过委托相关通行密钥的服务供货方将规避类似以上问题，并为监管规则提供成熟规模可靠的服务和合规基础建设支持。

## 常见问题解答

### 在企业中自建通行密钥解决方案的主要风险是什么？

在内部自建需要深厚的 WebAuthn 专业知识，并须持续进行浏览器和设备的兼容性管理及专门的安全维护。企业面临的风险包括延长部署时间、无法满足合规性审查以及采用率低。针对像银行业和医疗保健等受到严格监管的行业，[PSD2](https://www.corbado.com/blog/psd2-passkeys)、HIPAA 及
[NIST](https://www.corbado.com/blog/nist-passkeys)
的合规也加重了该复杂程度，而这些都是目前通行密钥相关服务商会接手并常态完成的服务范围。

### 在我安全地淘汰密码机制之前需拥有多少比例的使用受众？

在一个组织结构中必须存在约占 50%-80% 能够频繁采用并进行有效验证身份的使用受众时才能去衡量。在未达该标准前剔除密码极容易引出如体验差劣和支援疲乏的客诉。比较好的作法应采用基于数据见解，从对使用通行密钥驾轻就熟的使用群逐渐扩散并采用如推送的方式使多点提示让比率攀升的作法来进行淘汰作业（受多次要求在移动设备方面最高能够推升接受并促成达 85%）。

### 在对通行密钥实施部署的阶段，追踪哪一些 KPI 有助于推论衡量最终成效？

在包含的 KPI 监控选项中要包含接受度指标的监控（指标参考：初次推送 50-75% 及多次推送推高后的 85%），并且创建的设定值须近达百分之百成功率。而最终可供验证的数据输出为能在几周内维持至多 20%，并在一年之内保持在半数占比上的登陆。最后，将按操作和硬件设备的平台细致分门别类出在何处有着较弱的呈现。

### 为什么在技术面上已是完善的通行密钥部署却仍在实际上迎来失败？

造成绝大多数在通行密钥实施后仍不能大放异彩的多数核心原因是出于客户较低的响应接受状态而不是源自科技层面的错误因素造成的。一直使用既有的登录导致抵消并磨灭所带来具有降低简讯 MFA 所产生的各项优劣表现更不用说是在重发方面的劣势。像是 Amazon 和 Google 是在经过对采纳者不断的实验以并对接口在交互推广下进行有效和引导下促成的。

### 较之采取在公司自己建设使用外部供货商实施方案能够从中获取并改善的行业有些？

主要在银行金融、政府部门机构与医疗系统、以及电商、通讯、保险相关领域在使用后由于像要符合相关规范如 HIPAA 及
[PSD2](https://www.corbado.com/blog/psd2-passkeys) 及 [NIST](https://www.corbado.com/blog/nist-passkeys)
相关复杂繁杂的基础框架并在面向如此广大基数能够提供良好的运用，因为 Amazon 目前已然设下了完全不再仰赖现有基于登录机制的大胆采用的未来宏图来印证这个广大的前景。
