WebAuthn Resident Key：作为 Passkey 的可发现凭证

Passkeys 和底层的 WebAuthn 协议正在彻底改变身份验证领域。然而，正确设置 WebAuthn 服务器可能是一项棘手的工作。错误的配置不仅会引入漏洞，而且如果您以后需要更改它们，还可能会破坏现有的 passkey。这篇博文将帮助您更好地理解通常很复杂的 WebAuthn 规范，并为您提供针对您的用例的最佳设置建议。

WebAuthn 与三个主要实体一起运作：

• 信赖方 (Relying Party, RP)： 这是希望对用户进行身份验证的 Web 服务。它向客户端发送质询，验证响应并管理 passkey 的公钥。
• 验证器 (Authenticators)： 这些是可以证明凭证所有权的设备。例如智能手机、笔记本电脑或安全密钥（如 YubiKeys）。验证器可以是特定于平台的（如 Windows Hello 或 Apple 的 Touch ID / Face ID），也可以是跨平台的（如安全密钥，例如 YubiKeys）。
• 客户端 (Clients)： 通常是 Web 浏览器或原生应用，充当 RP 和验证器之间的中介。它们促进通信，确保数据正确安全地流动。

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

下面描述了身份验证过程（登录或注册）中的高级数据流。

1. 客户端启动： 该过程始于客户端，通常是用户尝试登录或注册时。例如，他们可能点击“使用 WebAuthn 登录”按钮，客户端会向 RP 发送一个请求质询的请求。
2. RP 请求： RP 随后向客户端发回一个质询。该质询是一个随机生成的值，用于确保后续响应的真实性。
3. 客户端到验证器： 在注册期间，客户端请求验证器通过创建相应的公私钥对来创建一个新的 passkey。在登录期间，客户端请求验证器对质询进行签名。这是使用验证器上的私钥完成的，该私钥对应于先前在 RP 上注册并存储的公钥。
4. 验证器响应： 在注册期间，验证器将公钥发回给客户端。在登录期间，验证器对质询进行签名，并将这个已签名的断言发回给客户端。
5. 客户端到 RP： 客户端将这个新的公钥或已签名的断言转发给 RP。
6. RP 验证： RP 存储公钥或使用存储的公钥验证已签名的断言。如果有效，则身份验证成功。

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

上述高级流程描述了 WebAuthn 的注册和登录过程。Passkeys 是建立在 WebAuthn 之上的。最初，passkeys 这个术语被用作一个比 WebAuthn 更易记、更非技术的术语，描述的是同一件事。此外，与标准的 WebAuthn 相比，passkeys 提供了更多功能，例如通过云账户或密码管理器同步 passkeys 的可能性。

为了更好地理解以下部分，我们定义一些 WebAuthn 协议中的重要术语，以达成共识。

• 凭证 ID (Credential ID)： 凭证 ID 是分配给由验证器生成的特定公钥凭证的唯一标识符。它允许信赖方 (RP) 识别和选择正确的 PublicKeyCredential 以进行身份验证过程。
• PublicKeyCredential： 这是从浏览器或原生应用的 WebAuthn API 返回的主要数据结构。它在注册期间包含证明 (Attestation) 数据，在登录期间包含断言 (Assertion) 数据。基本上，它包含了 RP 验证过程所需的数据。
• 证明 (Attestation)： WebAuthn 环境中的证明可作为验证器来源及其完整性的证据。在注册期间，这是验证器的一种表达方式：“我已经安全地注册了用户的凭证，这里有一份声明，您可以用它来验证”。然后，信赖方可以验证签名是否来自允许的特定验证器（例如 Yubikey）。并非所有的 passkey 验证器都会回复这样的证明，有些只是不发送有用的数据回来（请参阅此处的 passkey 验证器列表）。更多识别验证器（主要是安全密钥，如 YubiKeys）的 AAGUIDs (Authenticator Attestation GUIDs) 可以在 FIDO 联盟元数据服务中找到。
• 断言 (Assertion)： 在注册过程之后，当用户尝试登录时，验证器会生成一个断言。断言基本上是 PublicKeyCredential + 签名的质询。该断言证明用户拥有与注册公钥关联的私钥，而无需透露实际的私钥。这是验证器的一种表达方式：“这是真正的用户，我可以为他们担保。”

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Resident key (RKs) 和 non-resident key (NRKs) 是 WebAuthn 协议中使用的两种加密密钥，它们主要在存储位置和检索机制上有所不同。

定义：

Resident key 直接存储在验证器本身上。这可能是一个安全密钥（例如，YubiKey）、平台的安全区域（例如，iPhone 的安全区域）或笔记本电脑上的可信平台模块 (TPM)。Conditional UI (passkey 自动填充) 只对 resident key 有效，并且 WebAuthn 工作组目前要求将 resident key 视为 passkey。

在下面的截图中，您可以看到存储在 YubiKey 上的所有 resident key（凭证 ID、rpID、用户名、显示名称）的列表。Non-resident key 不在此列表中，因为它们不存储在验证器上：

登录流程：

来源：William Brown

在登录过程中，信赖方发送一个不指定凭证的请求给客户端（浏览器），客户端开始查询验证器（图表中的安全密钥）。验证器发现所有与相应信赖方匹配的 resident key，客户端（浏览器）选择所需的 resident key。这个 resident key 用于对质询进行签名。签名从验证器通过客户端发送到信赖方。

优点：

1. 简化的用户体验： resident key 最显著的优点之一是验证器存储了用户句柄（例如电子邮件、电话号码、用户名），因此可以预填充用户句柄（例如电子邮件、电话号码、用户名）以进行登录。用户无需记住或输入用户句柄（例如电子邮件、电话号码、用户名），从而简化了登录过程，尤其是在具有生物识别功能的设备上。这也可以通过 Conditional UI 自动完成。
2. 特定于设备的身份验证： Resident key 可以通过将身份验证与特定设备绑定来提供额外的安全层。这对于希望确保用户从受信任设备登录的服务特别有用。
3. Conditional UI (Passkey 自动填充)： Conditional UI 仅适用于 resident key，提供最无缝的登录体验（详见下文）。

缺点：

1. 存储限制： 一些验证器的存储容量有限。特别是对于安全密钥（例如 YubiKeys），它们可以存储的 resident key 数量通常有限制（大多数限制在 8 到约 100 个之间）。一旦达到此限制，可能需要删除旧密钥以为新密钥腾出空间，或者用户可能需要使用另一个验证器。
2. 验证器丢失： 如果验证器，例如安全密钥（例如 YubiKey）或智能手机丢失或损坏，该设备上的所有 resident key 都会丢失。这可能会导致用户被锁定在多个服务之外，直到他们重新注册或恢复其帐户。通过云账户（例如 iCloud 钥匙串、Google 密码管理器）或现代密码管理器（例如 1Password 或 Dashlane）同步密钥可以防止这种损失。
3. 安全问题： 如果带有 resident key 的验证器被盗，攻击者可能会尝试提取密钥。虽然现代验证器具有强大的安全机制来防止提取，例如用户使用强 PIN、密码或手势保护设备，但风险虽然很小，但仍然存在。

用例： 适用于用户经常进行身份验证的设备，如个人智能手机或笔记本电脑。

Want to find out how many people use passkeys?

View Adoption Data

定义：

相比之下，non-resident key 不存储在验证器上。而是在注册期间，验证器生成一个新的密钥对（基于其内部保护的主密钥），并将这个新密钥对的公钥连同凭证 ID（包含一个种子）一起发送到服务器（信赖方）。然后服务器将此公钥与用户帐户关联。对于后续的身份验证，验证器通过接收凭证 ID，提取种子并将其与主密钥组合来重新派生私钥。因为该密钥仅在验证器的受保护内存中临时可用，所以在密码学术语中有时被称为临时密钥 (ephemeral key)。

登录流程：

来源：William Brown

在登录过程中，信赖方必须首先识别哪个用户正在请求身份验证（例如通过询问用户句柄，如电子邮件、电话号码或用户名），然后将其知道的请求用户的凭证 ID 发送到客户端（浏览器）。客户端将它们转发到验证器（此处为安全密钥）。验证器使用凭证 ID 和验证器的主密钥来派生临时私钥，用生成的密钥对质询进行签名，并将其返回给客户端（此处为浏览器），客户端再将其转发给信赖方。Non-resident key 最初在 passkey 引入之前用作第二因素。因此，首先识别用户是常规登录过程的一部分。

优点：

1. 可扩展性： 由于 non-resident key 不驻留在验证器上，用户可以拥有几乎无限数量的与各种服务关联的 non-resident key。这对于在众多平台上拥有帐户的用户尤其有益。
2. 漫游能力： Non-resident key 非常适合漫游验证器，如安全密钥（例如 YubiKey）。用户可以使用同一个安全密钥（例如 YubiKey）在多个设备和平台上进行身份验证，提供一致的体验。
3. 减少对验证器存储的依赖： 对于合适的 WebAuthn 服务器设置，无需担心验证器的存储限制。这对于低存储验证器，如安全密钥（例如 YubiKeys），尤其有利。

缺点：

1. 用户体验较差，需要用户句柄： non-resident key 最大的缺点是用户需要提供用户句柄（例如电子邮件、电话号码、用户名），这使得通过 Conditional UI 进行用户名预填充成为不可能。此用户句柄需要与凭证 ID 绑定，凭证 ID 是计算临时密钥包装密钥所必需的。
2. 潜在的管理不善： RP 需要管理和保护用户帐户与公钥之间的关联。管理不善或漏洞可能导致安全问题。

用例： 适用于跨多个服务或平台使用的漫游验证器，如安全密钥（例如 YubiKeys）。

想象一下，您有一个安全密钥（例如 YubiKey），您用它注册了两个在线服务：服务 A 和服务 B。对于服务 A，您使用 resident key。对于服务 B，您使用 non-resident key。当您向服务 A 进行身份验证时，您只需轻触您的安全密钥（例如 YubiKey），就登录了——无需指定用户名。对于服务 B，您首先需要在浏览器/原生应用中提供您的用户名。然后，该服务将关联的凭证 ID 发送到您的安全密钥（例如 YubiKey），后者会重新生成用于身份验证的临时私钥。

从本质上讲，虽然 resident key 和 non-resident key 都通过利用加密身份验证来增强安全性，但它们的用户体验和存储机制不同，以适应不同的用例。

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Conditional UI 是 passkeys / WebAuthn 的一个里程碑式功能。它为用户减轻了更多负担，因为用户不仅不需要记住密码，甚至不需要记住他们注册信赖方时使用的用户句柄（例如电子邮件、电话号码、用户名）。特别是在信赖方服务不经常使用的情况下，这是一个巨大的进步。

这是因为一旦登录页面打开，信赖方服务器就会在后台向客户端发送一个质询（请记住，在此调用中不需要发送凭证 ID）。客户端接收此质询并检查此验证器上哪些 passkey 与信赖方 ID 匹配，并通过自动填充菜单提供选择，用户可以在其中选择适当的 passkey。

此外，它还为用户省去了额外点击登录按钮的麻烦，因为一旦从自动填充菜单中选择了 passkey，登录过程就开始了。

CTAP 是 FIDO2 标准中的一个基础协议，弥合了客户端（如浏览器）和验证器（如安全密钥，例如 YubiKeys 或智能手机）之间的通信鸿沟。为了更好地理解 CTAP，让我们在分析其对 resident key 和 non-resident key 的影响之前，先简要了解一下不同的协议版本。

早期版本，通常称为通用第二因素 (Universal 2nd Factor, U2F)，主要设计用于第二因素身份验证。在 U2F 中，服务器提供一个质询，验证器提供一个响应，证明拥有私钥。然而，U2F 不支持 resident key，这意味着它总是需要服务器端查找来确定为用户使用哪个密钥，因为这是请求第二因素过程的一部分。

作为 U2F 的继任者，CTAP2 引入了对 resident key 的支持，从而实现了无密码和无用户名的身份验证。有了 resident key，验证器存储用户的用户名和凭证 ID（以及信赖方 ID），从而消除了信赖方服务器在身份验证期间提供它的需要。这是迈向更无缝用户体验的重大飞跃。

然而，CTAP2 也带来了挑战。一个显著的问题是 resident key 的管理。例如，在 CTAP2.0 设备中删除特定的 resident key 通常需要完全重置设备（因此您的主密钥也会被重置，这意味着您所有的 non-resident key 也将不再工作），这对用户不友好，并且在单个设备上存储多个 resident key 的情况下可能会出现问题。这使得 CTAP2.0 设备上的 resident key 成为一项严肃的承诺。您真的不想意外地填满您通常有限的空间，尤其是在安全密钥（例如 YubiKeys）上。

CTAP2.1 是 CTAP2 的后续版本，为协议带来了额外的功能和改进。关于 CTAP 2.1 的一些关键点包括：

• 更好的 Resident Key 管理： CTAP 2.1 允许您单独管理、更新和删除设备中的特定 resident key。
• 企业证明 (Attestation)： 此功能允许企业对其员工使用的密钥有更多的控制权。它为企业提供了一种验证正在使用的密钥是公司颁发的方法。
• 多用户识别： 一些验证器可以识别多个用户。CTAP 2.1 为这些验证器提供了一种指示已识别哪个用户的方法。
• 向后兼容性： CTAP 2.1 设计为与 CTAP2 向后兼容，确保支持旧版本的设备和平台仍然可以与新版本一起工作。

在了解了 resident key、non-resident key 和不同的 CTAP 版本之后，我们现在更深入地分析信赖方侧，也就是 WebAuthn 服务器侧。

WebAuthn 的灵活性（也是其复杂性）在很大程度上归因于其服务器设置，特别是在 authenticatorSelection 对象中。该对象指导客户端为任务选择正确的验证器。

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

此服务器选项指定验证器如何附加到客户端设备。它提供了有关验证器如何与客户端通信的见解：

可能的值

• Platform：表示验证器附加到客户端的平台，因此不可移动。
• Cross-platform：表示验证器不绑定到客户端的平台，可以在多个设备上使用。

用例和示例

• Platform： 示例包括笔记本电脑内置的指纹扫描仪或手机上的面部识别系统，例如 Face ID、Touch ID 或 Windows Hello。
• Cross-platform： 示例包括 USB 安全密钥（例如 YubiKeys）、蓝牙设备或 NFC 卡。

在 WebAuthn Level 1 规范中，此服务器选项称为 requireResidentKey，可以取布尔值 true（验证器必须创建 resident key）或 false（验证器必须创建 non-resident key）。WebAuthn Level 2 将此服务器选项替换为新的服务器选项 residentKey：

可能的值

• Required： 验证器必须创建 resident key（如果不可能，操作应失败）。
• Preferred： 验证器应尝试创建 resident key（如果不可能，应创建 non-resident key）。
• Discouraged： 验证器必须创建 non-resident key（如果不可能，操作应失败）。

用例和示例

• Required： 适用于希望实现无用户名登录或用户只应从先前注册的设备进行身份验证的场景（通过将用户凭证绑定到特定设备来增加额外的安全层）。
• Preferred： 适用于 Web 服务希望在可能的情况下提供最佳登录用户体验（通过 resident key），但如果 resident key 不可用，仍希望支持 non-resident key 的场景。
• Discouraged： 服务希望提供passkey 身份验证，并希望确保用户可以使用任何验证器，即使是那些没有存储能力的验证器，而无需将凭证绑定到特定设备。

用户验证指的是确保与验证器交互的人是合法所有者的过程，通常通过要求特定的身份验证手势，如输入 PIN、提供指纹或使用面部识别。

有时用户在场 (UP) 也被提及或与用户验证类似地使用，但确实有一些区别。用户在场仅确认有人——任何人——物理上在场并与设备交互。它不验证该人的身份。简单地触摸安全密钥，无需任何进一步的身份检查，就足以满足用户在场的要求。对于 passkeys / WebAuthn，用户总是需要在场。

可能的值

• Required： 操作必须有用户验证。
• Preferred： 操作应尽可能有用户验证，但也可以在没有的情况下继续。
• Discouraged： 操作不应有用户验证。

用例和示例

• Required： 适用于高安全性应用，如银行或医疗保健，其中验证用户身份（例如，通过指纹或 PIN）至关重要。
• Preferred： 适用于一般应用，其中增加的安全性是加分项但并非严格必需。
• Discouraged： 适用于低风险操作或用户验证可能带来不便的场景。

模式

• Authenticator attachment: platform
• Resident key: required
• User verification: required

示例： 一个企业应用程序希望员工在其公司配发的笔记本电脑上使用内置的指纹读取器进行无密码登录。凭证存储在设备上，用户每次都必须使用指纹进行验证。

模式

• Authenticator attachment: cross-platform
• Resident key: required
• User verification: required

示例： 用户为其在线银行注册一个安全密钥（例如 YubiKey）。他们可以通过提供安全密钥（例如 YubiKey）在任何设备上使用此密钥进行身份验证，而无需输入用户名。

许多基于硬件的安全密钥（例如 YubiKeys）具有固有的存储限制。此限制是由于设备上的物理内存以及制造商的设计考虑。

示例： 一个 YubiKey 可能只能存储 20 个 resident key。一旦达到此限制，就无法在不删除现有密钥的情况下添加额外的 resident key。

解决方案：

• 有选择地使用 Resident Key： 不要为每个用户都使用 resident key，而是考虑将它们用于特定角色或场景。例如，为需要增强安全性的管理员角色或高权限用户优先使用 resident key。
• 用户教育： 告知用户其安全密钥（例如 YubiKeys）的限制。鼓励他们切换到可以使用无限 resident key 的设备，例如笔记本电脑或智能手机。

不同的验证器可能以不同的方式处理 resident key 请求。有些可能默认创建 resident key，即使没有明确要求，而另一些则可能需要明确的指令。

不同WebAuthn 服务器选项在不同平台上的不一致行为是一个主要问题。例如，iOS 无论传递给它的 WebAuthn 服务器选项如何，总是会创建一个 resident key，而 Android 则需要选择加入（例如，使用 residentKey: preferred 或 residentKey: required）。

除了行为之外，更糟糕的是，根据服务器端存储的数据，您无法 100% 确定存储的凭证是 resident key 还是 non-resident key。相反，您可以遵循一些检查并缩小范围（见下文），但仍需希望凭证的行为与您的信念一致。

其背后的原因是 WebAuthn 建议在凭证属性扩展 (clientExtensionResults.credProps.rk，值为 true 或 false) 中存储有关凭证类型（resident key 或 non-resident key）的信息。然而，向 RP 提供此信息并不能保证，因为所有 WebAuthn 扩展都是可选的，例如 iOS 不发送它（所以您不知道它是 resident key 还是 non-resident key）。

在我们的研究中，我们尝试在不同平台和验证器（Windows 10、Windows 11、Android 7、Android 13、iOS17、macOS Ventura、YubiKey）上使用两个提供有关创建凭证更多详细信息的 WebAuthn 演示页面进行测试：https://webauthn.io 和 https://webauthntest.identitystandards.io/。后者提供了使用旧的 requireResidentKey 属性（WebAuthn Level 1）甚至将其与 residentKey 属性（WebAuthn Level 2）结合使用的可能性。然而，结果并不可靠（例如，它为 iOS 显示为 non-resident key，但 conditional UI 显然是有效的）。

我们发现的最值得信赖的检查方案如下：

1. 检查您的 WebAuthn 服务器设置中“residentKey”属性的值
   1. 如果“residentKey: required”且成功创建凭证 -> 它是 resident key
   2. 如果“residentKey: preferred”或“residentKey: discouraged”，则进行下一步检查
2. 服务器上的凭证是否支持并存储了扩展 credProps.rk？
   1. 如果 credProps.rk = true，则凭证是 resident key
   2. 如果 credProps.rk = false，则凭证是 non-resident key
   3. 如果 credProps 为空，则凭证类型未知

如您所见，这有助于缩小范围，但仍然存在未知选项，您无法 100% 确定密钥类型。

这也与 SUSE 的 William Brown 在其精彩文章中的发现一致，该文章概述了如果信赖方要求使用 resident key，安全密钥（例如 YubiKeys）可能会变得无用（我们扩展了他的表格）：

在下表中，您可以看到对于不同的 WebAuthn 服务器 resident key 选项，是否创建了 resident key（true）、是否创建了 non-resident key（false）或者发生了其他情况。

解决方案：

• 全面测试： 在部署之前，在一系列流行的验证器上测试您的 WebAuthn 实现，以了解它们的行为。
• 明确的服务器设置： 在设置您的 WebAuthn 服务器时，要明确您的要求。如果您只想拥有 passkey，则将 residentKey 选项设置为 required（注意：这可能会导致其他挑战，例如验证器 resident key 容量有限，见上文）。

如果用户的安全密钥（例如 YubiKey）达到存储上限，他们可能会遇到错误或无法注册新凭证。这可能导致困惑和挫败感。

解决方案：

• 优雅的错误处理： 实现清晰的错误消息，告知用户其安全密钥（例如 YubiKey）已满，并提供如何解决问题的指导。
• 引导式工作流程： 提供有关用户如何管理其 resident key 的分步指南或教程，确保他们可以独立解决问题。

9. 开发人员和产品经理的最佳实践

如上所述，您选择的 WebAuthn 服务器设置会显著影响用户体验和身份验证过程的安全性。了解这些设置的细微差别以做出明智的决定至关重要。

Resident Key 与 Non-resident Key： 如果您的大多数用户主要从个人设备（如智能手机或笔记本电脑）访问您的服务，resident key 是一个合适的选择。Resident key 存储在设备本身，为经常使用同一设备的用户提供无缝的身份验证体验。然而，对于使用安全密钥（例如 YubiKeys）的用户，non-resident key 可能更合适。

用户验证 (UV) 设置： 根据您希望达到的安全级别，您可以决定用户验证过程的严格程度。如果您的目标是高安全性，建议要求 PIN、指纹或面部识别（userVerification: preferred 或 userVerification: required）。

证明 (Attestation) 和可信度： 证明允许您验证验证器的来源和完整性。决定您是想信任所有验证器，还是只信任来自特定制造商的验证器。如果您处理敏感数据并希望确保只使用高质量、受信任的验证器，这一点可能至关重要。

后备机制： 始终准备好后备机制。如果用户丢失其验证器或验证器发生故障，他们应该有另一种方式访问其帐户。这可以通过备份代码、短信验证、电子邮件魔法链接或其他多因素身份验证方法实现。

持续学习： passkeys 和 WebAuthn 的领域在不断发展。随时了解最新的发展、漏洞和补丁。鼓励您的开发团队参加与 passkeys 和 WebAuthn 相关的研讨会、网络研讨会和会议。

用户引导和教育： 在引入passkey 身份验证时，确保您的用户了解其好处以及它如何工作。在注册过程中提供清晰的说明，并提供资源（如常见问题解答或视频教程）以帮助用户设置和使用 passkey。

通过遵守这些最佳实践，开发人员和产品经理可以确保他们有效地实施passkey 身份验证，平衡安全性和用户体验。

如果您想在您的网站或应用中为主流用户实施 passkey，并且不需要支持安全密钥（例如 YubiKeys），因为您的大多数用户只会使用他们的智能手机或笔记本电脑，我们推荐以下设置。

• authenticator: platform
• residentKey: required
• userVerification: required

好处：

• 由于所有创建的密钥都是 resident key，此设置允许 Conditional UI，使您的用户登录更加无缝，因为他们不必记住用户名。
• 所有来自 Apple、Google 和 Microsoft 的现代设备都受支持并使用 passkey。

WebAuthn 的服务器设置虽然复杂，但为身份验证提供了一个强大而灵活的框架。掌握这些设置至关重要，因为它不仅仅是实施一个新标准；它关乎从根本上提高用户身份验证的安全性和效率。

从本质上讲，理解 WebAuthn 的服务器设置是对构建更安全、高效和具有前瞻性的应用程序的一项投资。随着数字领域的不断发展，精通此类技术将是不可或缺的。要保持更新，请加入我们的 passkeys 社区或订阅下面的新闻通讯。