Passkey 通行密钥怎么工作：注册登录流程、rpID 作用域与五个误区

Passkey（通行密钥）用一对非对称密钥替代密码登录：私钥留在手机、电脑或硬件密钥里，服务器只保存公钥。它把记密码和填验证码合成一次本地解锁，同时把凭据绑定到具体域名，钓鱼站拿不到可复用的东西。2026 年 8 月 25 日，WebAuthn Level 3 成为 W3C 正式推荐标准，接入所需的能力探测、条件式界面与跨域复用有了稳定依据。

Passkey 是什么：私钥留在设备，公钥存在服务器

先分清三个角色。Relying Party（RP，依赖方）是提供登录的网站；authenticator 是真正持有私钥的那一端，可以是系统内置的平台认证器，也可以是 U 盘形态的安全密钥；浏览器或操作系统充当客户端，负责在两者之间转递请求。

Passkey 在规范里的正式名字是可发现凭据（discoverable credential），也叫常驻凭据。它把私钥、凭据 ID、用户句柄和元数据一起存在认证器里，登录时不必先输入用户名，浏览器就能把可用凭据直接列出来。

私钥不会离开认证器，服务端只保存公钥和凭据 ID。指纹、面容或设备 PIN 只是解锁私钥的本地授权手势，它本身不是凭据，也不会上传到服务器。把 passkey 等同于刷脸登录，是常见的混淆点之一。

也正因为私钥不出设备，服务端数据泄露不会直接导致账号被接管。攻击者拿到公钥和凭据 ID，没有对应私钥，仍然签不出能通过校验的断言。

注册与登录：两个仪式里 challenge 和签名怎么走

WebAuthn 把流程拆成两个仪式（ceremony）：注册建凭据，认证用凭据。两边都围绕一个由服务端生成的随机 challenge 展开。

注册一侧大致分四步：

1. 服务端生成 challenge 与创建选项，其中包含 rp.id、user.id 和可接受的签名算法，例如 ES256 对应 -7、EdDSA 对应 -8、RS256 对应 -257。
2. 前端调用 navigator.credentials.create()，把选项交给客户端。
3. 认证器生成密钥对，先做一次本地用户验证，再返回凭据 ID、公钥与可选的认证声明。
4. 服务端校验 challenge 与来源，保存公钥并绑定到账号。

登录一侧的顺序与之对称。服务端发 challenge 和允许的凭据列表，前端调用 navigator.credentials.get()，认证器用私钥对 challenge 签名，服务端拿先前保存的公钥验签。

验签之外还有几项核对不能省：challenge 是否与本次会话一致，origin 是否属于该 RP，认证器数据里的 rpIdHash 是否匹配。漏掉其中任何一项，抗重放与抗钓鱼的前提就不成立了。

抗钓鱼的根据：rpID 作用域与 Related Origin Requests

Passkey 抗钓鱼不靠用户辨认域名，靠浏览器强制执行作用域。每条凭据在创建时就绑死一个 Relying Party ID（rpID），通常是注册域，例如 example.com。登录时浏览器检查当前页面是否属于这个 rpID，不属于就不提供该凭据。

所以在 example-login.com 这类仿冒域名上，用户根本看不到 passkey 提示，也没有忽略警告继续的选项。短信验证码和 TOTP 不同，它们可以被反向代理式钓鱼站实时转发，这是两类方案在安全模型上的根本差别。

子域可以共用：example.com 的凭据在 login.example.com 上同样可用。跨注册域则不行，shopping.com 的凭据在 shopping.co.uk 上不会被提供。多国域名或多品牌的部署，正规解法是 OpenID Connect 一类联邦登录；只有在联邦做不了时，才考虑 Related Origin Requests（ROR）。

ROR 的做法是在 rpID 域名下托管一份 JSON：路径为 /.well-known/webauthn，内容类型 application/json，origins 数组列出被认可的来源，与 rpID 自身匹配的条目不要重复写进去。

示例：https://shopping.com/.well-known/webauthn 返回 origins 数组，内含 https://shopping.co.uk 与 https://myshoppingrewards.com 这类条目。

限制在于标签数。标签指有效域名后缀（eTLD）前的那一段，shopping.com 与 shopping.co.uk 都算 shopping 这一个标签。规范要求客户端至少支持 5 个不同标签，目前没有已知客户端支持更多，因此 5 是实际可用的上限。

前端可以查 getClientCapabilities() 返回里的 relatedOrigins 键，判断当前浏览器是否支持这条路径。完整部署说明见 passkeys.dev 的 ROR 文档。

同步 passkey 与设备绑定 passkey：BE/BS 标志说明什么

Passkey 有两种形态，选型时经常被混为一谈。

Level 3 新增两个标志位来区分它们。Backup Eligible（BE）在创建仪式里置位，说明这条凭据允许被备份，也就是同步 passkey；Backup State（BS）可以在每次认证时变化，表示它当前是否真的已备份。规范建议把未带认证声明的消费级 passkey 默认按同步处理，细节见FIDO 联盟对 L3 的说明。

BS 的用法目前还没铺开。多数凭据管理器对同步凭据恒定置 1，用它提示凭据已被移出备份的玩法仍属少数。做服务端判断时，不要把 BS 当成可靠的安全控制。

另一处改动与凭据管理界面有关。过去认证声明设为 none 时，AAGUID 会被填成全零，RP 只能猜用户把凭据存在哪家管理器。L3 允许无认证声明时也传 AAGUID，网站就能在账号设置里按名称和图标列出每条凭据来自哪个管理器。

与合规相关的一条常被引用：可同步的 passkey 只到 NIST SP 800-63B 的 AAL2，要满足 AAL3 需要带认证声明的设备绑定认证器。这一说法来自第三方开发者指南的实践总结，落地前应按自身合规要求核对原文。

落地步骤：从能力探测到条件式界面

把 passkey 接进现有登录页，顺序比代码细节更重要。可以按下面五步推进。

1. 探测能力：调用 PublicKeyCredential.getClientCapabilities()，看 passkeyPlatformAuthenticator、conditionalGet、conditionalCreate、relatedOrigins 这几个键，而不是继续依赖两个旧的 is 系列静态方法。
2. 接条件式取回：给用户名输入框加 autocomplete="username webauthn"，页面加载时以 mediation: 'conditional' 调用 get()；用户改用表单登录时，用 AbortController 中止它。
3. 接自动升级：用户用密码登录成功后，在后台以条件模式调用 create()。服务端必须接受这次创建里的 UP=0 与 UV=0，并单独开一个与登录会话绑定的端点。
4. 简化序列化：用 parseCreationOptionsFromJSON()、parseRequestOptionsFromJSON() 与 toJSON() 处理二进制字段，省掉手写 Base64URL 转换。Chrome 与 Edge 从 129 版本起提供这组方法。
5. 补状态同步：用 Signals API 的 signalUnknownCredential()、signalAllAcceptedCredentials()、signalCurrentUserDetails() 告知客户端凭据已失效、有效凭据全集或用户资料变更。

条件式创建有三个前提：浏览器、操作系统与凭据管理器都支持该能力；用户没有在管理器里关掉这个开关；登录用的密码是从凭据管理器自动填充的。任一条件不满足，创建都会静默失败，因此这段逻辑必须允许失败而不打断登录。

Signals API 设计成发后不理，调用即返回，是否真的被采纳要到下一次认证才看得出来。规范编辑者的解读里把这层取舍讲得比较清楚：RP 与凭据管理器之间刻意没有直接通道，只能靠这类单向信号协调。

常见误区与上手建议

几个流传较广的说法，值得逐条核对。

• 误区一：有了 passkey 就不再需要备用登录。同步 passkey 依赖云账号，云账号丢了仍要走恢复流程；恢复若回落到邮箱重置，钓鱼风险随之回来。恢复链路要和 passkey 一起设计。
• 误区二：passkey 就是生物识别登录。生物识别只是本地授权手势，凭据是密钥对，两者在服务端可见的信息完全不同。
• 误区三：上线就等于会被使用。FIDO 联盟 2025 年 10 月发布的 Passkey Index 显示，参与统计的账号里 93% 具备条件、36% 已注册，全部登录中约 26% 走 passkey。差距更多来自提示出现的位置，而不是技术本身。
• 误区四：开了 passkey 就没有钓鱼了。这一条只在登录主路径上成立。短信、邮件、人工客服这些回退口子仍然是钓鱼入口。
• 误区五：一条 passkey 能覆盖公司所有域名。默认不行，要么做联邦登录，要么按 ROR 托管那份 well-known 文件，并接受 5 个标签的上限。

是否值得现在接，取决于账号规模和风险。面向外部用户的站点收益比较直接：Passkey Index 里同批企业报告登录耗时从 31.2 秒降到 8.5 秒，成功率从 63% 升到 93%，与登录相关的客服工单减少 81%。内部系统如果账号量小、设备型号杂，先把恢复流程与条件式界面做扎实，比追求覆盖全部用户更实际。

个人用户这一侧，上手顺序是先在主力账号里建一条同步 passkey，再补一条设备绑定凭据或安全密钥作为第二条路径，最后确认账号的恢复邮箱与备用码在手上。想比较密码管理器与两步验证工具的取舍，可以参考站内这份开源密码管理器与两步验证工具清单。

站点运维这一侧，passkey 只在 HTTPS 下工作，域名与证书是前置条件。多域名部署之前，先把证书申请与续期流程理顺，站内这份从零到上线的建站指南把域名解析、证书与回调配置串了一遍，能省掉一类登录失败。