Passkeys 与 WebAuthn：浏览器中的登录旅程
从注册到登录了解 passkey 的完整流程，区分浏览器与服务器的验证职责，并规划跨设备使用、账户恢复和无障碍替代方式。
Passkey 登录是一种由网站、浏览器、验证器和服务器共同协调的公钥认证流程。注册时，验证器创建一个限定给依赖方的凭据，服务器保存对应的公钥。登录时，服务器发出新的挑战，浏览器请求可用验证器使用匹配的私钥，服务器验证签名响应后才创建会话。浏览器负责协调用户选择并遵守安全边界，但不会替服务端决定账户是否获准访问。
W3C Web Authentication 规范定义了浏览器凭据操作和数据模型。MDN 的 Web Authentication API 指南介绍 JavaScript 接口，FIDO Alliance 的 Passkeys 概览说明 passkey 在设备和凭据管理器中的使用方式。这些资料有助于区分“证明对某站点凭据的控制权”与“可携带的身份证明”，也说明不能保证任何设备都能提供同一凭据。
Passkey 对浏览器意味着什么
Passkey 是一种可发现的 WebAuthn 凭据，使用一对密钥：私钥保留在验证器或凭据管理器中，依赖方保存对应公钥和凭据 ID。浏览器的 WebAuthn 接口通过 navigator.credentials.create() 和 navigator.credentials.get() 允许站点请求创建或使用凭据。浏览器和验证器负责面向用户的认证操作；站点仍需验证结果并作出账户决策。
依赖方（RP，relying party）是请求验证用户身份的网站或服务。其 origin 和 RP ID 限定了 WebAuthn 凭据的适用范围。站点不能随意要求浏览器把凭据用于无关 origin。WebAuthn 面向安全上下文，浏览器将 localhost 作为开发例外。嵌入式或跨源 frame 还受额外策略限制；顶层页面可以使用凭据，不代表 frame 自动获得无限制访问权。
“Passkey”描述的是一种凭据体验，并不意味着只有一种存储方式。凭据提供方可能在同一账户生态的设备间同步凭据，也可能将凭据绑定在单台设备或安全密钥上，还可能支持跨设备认证。这些方式的可用条件和恢复路径不同。API 存在、平台验证器可用或浏览器返回凭据，都不能证明某人的法律身份、共享设备由谁操作，或某个站点是否存在对应账户。
还要区分用户在场与用户验证。在场表示验证器观察到了交互；用户验证表示验证器执行了本地检查，例如设备 PIN、设备解锁码或生物识别。依赖方可以请求相应验证偏好，并应依据自己的策略检查返回标志。常规 WebAuthn 认证不会把生物特征模板发送给服务器；服务器收到的是用于验证签名和凭据属性的协议数据。
站点应分阶段描述结果。“Passkey 可用”不等于“Passkey 已注册”；“已返回凭据”不等于“账户已认证”；“签名有效”也不等于“用户获准执行所有操作”。明确区分这些状态，可以避免界面夸大结果，也便于定位失败。浏览器能力信号的隐私影响见 WebAuthn 指纹识别指南；本文聚焦用户的注册、登录和恢复旅程。Credential Management 登录指南则讨论浏览器中介的密码和联邦凭据，而不是 WebAuthn 协议细节。
注册凭据时避免过度承诺
注册应由明确的用户操作开始，例如在账户安全设置中选择“创建 Passkey”。服务器创建短期有效的注册挑战，并返回浏览器所需的创建选项：挑战、RP ID 和显示名称、用户句柄、接受的公钥算法、验证器偏好，以及需要排除的已有凭据。由于 passkey 必须是可发现凭据，请求必须要求创建可发现凭据，例如设置 authenticatorSelection.residentKey: "required"；不能静默退回不可发现凭据后仍称之为 passkey。挑战及其账户关联由服务器负责，客户端不应自行生成或无提示地重复使用注册状态。
页面将这些选项传给 navigator.credentials.create({ publicKey })。浏览器检查上下文、策略和可用验证器是否允许请求，然后显示自己的界面。用户可选择设备或凭据管理器、解锁并确认。设置 residentKey: "required" 后，注册必须创建可发现凭据，否则操作失败；平台无法满足要求时，不应悄悄降低要求。用户可能取消、更换方式或遇到平台限制。页面应将这些视为正常结果，同时保留账户设置流程。
注册流程成功后，浏览器返回包含客户端数据和 attestation 对象的凭据响应。Web 应用将响应连同标识待完成注册的状态一起发送到服务器。服务器确认挑战匹配且未过期、origin 获准、RP ID 哈希符合预期，并检查响应类型及凭据数据格式。它还要确认凭据可关联到正确账户，注册策略要求的是可发现凭据；当受支持的响应提供凭据属性时，应在将其登记为 passkey 前确认可发现属性。Attestation 只按已文档化策略所需的范围验证。
Attestation 可能泄露验证器来源信息。站点不应请求或保留超出威胁模型与用户告知所需的数据。许多面向消费者的服务可以接受较广泛的验证器，而不识别具体型号。过窄的策略可能排除合法用户、增加数据责任，并随着平台变化而过时。如果业务确有更严格的保证要求，应在注册前说明，并在受支持设备上验证完整体验。
验证注册后，服务器保存凭据 ID、公钥、账户关联，以及未来验证和管理所必需的最少元数据。不要保存私钥；WebAuthn 不会把私钥返回给站点。响应中可能包含计数器，但不同验证器和同步凭据的行为并不相同，因此不能把计数值单调增加当作通用盗用检测器。决定风险检查时，应依据现行规范和验证器的文档语义。
只有服务器确认按注册策略取得了可发现凭据后，页面才能说明 passkey 已添加。如果应用无法确认该属性，就不要把结果称为 passkey；应说明此方式目前不可用，并提供清楚且受支持的替代方案。显示易懂的名称，例如“此设备”或用户自选标签；必要时显示添加日期，并提供删除或重命名方式。不要根据推断出的硬件或身份信息标注凭据。账户安全页面还应说明，删除站点上的凭据记录不一定会删除设备生态中由提供方管理的副本；用户可能还需在提供方处管理该凭据。
使用新挑战完成认证
登录沿用相同的职责划分。用户选择使用 passkey 登录，服务器生成新的、不可预测且有效期有限的挑战。服务器同时确定允许的 RP ID、凭据策略、用户验证要求，以及需要绑定到认证流程的账户或交易上下文。对于先输入用户名的流程，服务器可以将允许的凭据 ID 限定为与该账户关联的凭据。对于无用户名、通过发现凭据登录的流程，验证器可能返回凭据和 user handle，服务器必须按明确的账户策略解析它们。
页面调用 navigator.credentials.get({ publicKey })。如果平台和中介规则允许，浏览器可能显示账户选择或 passkey 自动填充界面。用户选择或解锁验证器后，验证器会签署与挑战和依赖方相关的协议数据。跨设备登录时，用户可在另一台设备的浏览器中，通过中介流程选择手机或其他验证器。具体体验取决于浏览器、操作系统、凭据提供方及可用传输方式；应用不应承诺所有平台都会出现相同提示或使用相同传输方式。
认证响应包含客户端数据、验证器数据、凭据 ID 和签名。服务器确认挑战正是自己发出的、仍在有效期内且没有被使用过；还要检查客户端数据类型、允许的 origin、RP ID 哈希、凭据与账户的关联、用已保存公钥验证的签名，以及策略要求时的用户验证状态。之后服务器再应用账户状态、授权、速率限制和风险检查，决定是否创建会话。有效签名只是决策的一个输入，不等于会话本身。
挑战的生命周期需要谨慎管理。用密码学安全的随机源生成挑战，将其绑定到目标登录或敏感操作，设置较短的有效期并拒绝重用。不要把挑战放进 URL、分析事件或支持日志。使用应用常规的安全传输和服务端会话控制保护交换过程。验证失败时，不要相信浏览器提交的用户名、凭据标签或客户端“成功”标志。
不要把实现细节当作人的身份。凭据 ID 是依赖方账户系统中的标识，不是全局用户身份。User handle 应保持不透明且仅在该服务范围内使用。传输提示可以帮助浏览器选择路径，但不能证明验证器就在附近，或设备属于某位具名用户。账户选择和授权应以服务端记录为准，而不是依赖设备标签或浏览器能力。
规划可携带性与恢复
一些 passkey 由凭据提供方在用户的多个设备间同步。提供方可能使用端到端加密及账户恢复保护，但具体行为、可用性和设置方式因提供方而异。站点不应保证在一部手机上创建的凭据会立刻出现在另一部手机上、每个提供方都能与所有平台互通，或同步服务始终可用。账户或同步恢复应指向提供方当前的帮助资料；站点不应尝试检查或修复提供方的私有状态。
另一些凭据绑定在设备上，例如安全密钥，或私钥不会同步的验证器。它们可以作为持久的第二验证方式或组织管理的选项，但设备丢失或损坏时，依赖方需要另设恢复路径。跨设备认证则是另一种情形：用户用附近保存 passkey 的设备，完成在另一台设备上发起的登录。二维码或近距离交换有助于建立认证流程，但本身不能证明服务器验证已经通过。不要把同步、备份和跨设备使用都概括成“到处都能用”。
凭据提供方恢复与服务账户恢复是两项不同工作。提供方恢复用于重新访问凭据管理器或其加密凭据集合；依赖方恢复则是在无法使用已注册 passkey 时重新访问服务账户。网站通常无法修复丢失的提供方账户，也不能取回缺失的私钥。服务可根据政策提供另一把 passkey、已注册的安全密钥、恢复代码、经过审核的身份核验或谨慎设计的支持流程。每种路径的保证等级都应与账户价值和待恢复操作相匹配。
应在注册时就提供恢复说明，而不是等用户被锁在账户外时才出现。建议用户添加适当的第二凭据或恢复方式，并说明其保存位置。对于高价值账户，在替换所有验证器、修改恢复联系方式或停用现有方式前，应要求更严格的审核。策略允许时，在确认替代方式可用之前保留旧凭据，并在重要安全变更后清楚通知用户。支持人员不能仅因来电者知道公开的个人资料，就绕过相同的账户检查。
恢复页面也应防止账户枚举。公开的登录或恢复响应不应泄露某个邮箱或用户名是否注册了 passkey。在可行范围内使用相同的消息和相近的响应时间，并只在适当验证后执行账户专属步骤。不要把 passkey 响应或恢复秘密写入分析系统、支持工单、截图或复制的错误文本。仅保留最少且可审计的流程阶段与结果记录。
让提示、取消和替代方案无障碍
浏览器或操作系统负责大部分验证器提示界面，但网站负责外围体验。在打开提示前，用直白语言说明 passkey 是什么。指出涉及的账户和操作，告知用户浏览器可能会要求选择或解锁凭据，并提供清楚可见的替代方式。不要仅因页面加载或不可见计时器触发凭据请求。明确按钮和用户主动操作能让人和平台都理解当前意图。
取消是用户的选择。如果操作被拒绝或没有返回可用凭据，应让用户留在登录页，保留可以安全保存的信息，并把焦点移回有用控件。不要立即重新打开提示、反复催促或宣布账户不存在。只有应用能可靠区分时，才分别说明用户取消、网络故障或服务器拒绝。保护隐私的通用提示，优于泄露账户或凭据的内部状态。
无障碍流程应支持键盘、屏幕阅读器、缩放和本地化界面。使用具有明确无障碍名称的真实按钮。播报状态变化，但不要意外移动焦点。确保对话框与账户选项具有合理的焦点顺序和清楚的关闭方式。不要暗示 passkey 必须使用指纹：平台可能使用 PIN、设备解锁码、安全密钥交互或其他支持的本地验证方式。还应为无法使用设备主要生物识别输入方式的人提供说明。
替代方式应是经过规划的产品路径，而不是临时降级。根据服务需要，可提供另一枚已注册 passkey、安全密钥、带多因素认证的密码或账户恢复。无论使用哪种方式，都应执行相同的服务端授权规则，并防范暴力尝试和钓鱼。用户选择 passkey 后，不要静默切换到别的账户；更换方式时也不要丢弃未保存的工作。替代方式可能不够方便，但仍应易于理解、安全，并能被残障用户使用。
运行诊断可以记录粗粒度阶段，例如已发出选项、用户取消、已收到 assertion、服务端拒绝验证、已建立会话。不要记录挑战、凭据响应、签名、私人数据、完整客户端数据或原始 user handle。这样既能获得可靠性信息，也不会把登录遥测变成凭据收集系统。上线前检查数据保留期限、访问控制，以及指标是否可能关联到个人。
把隐私和服务器策略留在正确的位置
WebAuthn 对 origin 和 RP ID 的绑定有助于防止为一个依赖方创建的凭据被当作属于另一个依赖方。但它不会自动让所有认证系统都安全。服务器仍需正确管理挑战、维护允许的 origin 列表、使用安全会话 Cookie、检查授权、限制尝试频率、制定恢复规则并监控系统。活动会话被盗与 passkey 私钥被盗是不同问题，因此账户保护必须同时覆盖凭据生命周期与登录后的会话生命周期。
尽量减少认证过程中采集的信号。不要对验证器型号做指纹识别，不要把 API 可用性长期保存为设备身份，不要从账户选择器推断用户姓名，也不要用传输提示构建跨站画像。浏览器能力检查可用于决定当前交互是否显示某项操作，但不应据此发现账户、评定资格或断言设备由谁持有。只请求服务所需的协议选项；若限制某些验证器，应在用户遇到限制前解释原因。
实现团队应在实际支持的浏览器与操作系统组合上测试完整流程：注册、成功登录、凭据缺失或用户拒绝、挑战过期、origin 不匹配、服务器拒绝、第二设备登录、凭据删除和账户恢复。除了触摸，也要用键盘和屏幕阅读器验证。兼容性信息会变化；做出支持承诺前应查阅当前 WebAuthn 文档与浏览器兼容性数据。在一台设备上的成功演示，只能证明该条具体路径，不能证明所有环境都如此。
BotBrowser 支持在受支持的宿主操作系统之间使用可重复的浏览器配置文件，帮助团队在一致的配置输入下检查自己的 passkey 注册与登录界面。它不会创建、保存、同步、恢复或认证 passkey，也不控制浏览器中介流程、操作系统验证器、本地生物识别检查或依赖方服务器决策。可用它更方便地对比经过授权的应用流程，同时将浏览器、验证器提供方和服务端视为认证结果的不同责任方。
实际职责很清楚：用户主动开始；浏览器和验证器完成限定到依赖方的认证流程；服务器验证签名响应并决定是否创建会话；服务提供无障碍替代方式与恢复路径。各层职责明确后，passkey 可以简化登录，而不会引入系统无法兑现的可携带性、身份、隐私或恢复承诺。