Meet Corbado at Identiverse 2026 - Las Vegas, June 16Las Vegas
返回概览

通行密钥提供商:不同类型、AAGUID 及其采用

了解第一方/第三方通行密钥提供商与通行密钥身份验证提供商的区别,以及如何利用 AAGUID 管理 Android、iOS 和 Web 的通行密钥。

Vincent Delitz
Vincent Delitz

创建: 2024年3月25日

更新: 2026年5月28日

通行密钥提供商:不同类型、AAGUID 及其采用

本页由自动翻译生成。请阅读英文原文 此处.

PasskeysCheatsheet Icon

Passkeys 速查表. 面向 passkey 项目的实用指南、推广模式和 KPI。

获取速查表
关键事实
  • 存在两个主要类别:第一方/第三方通行密钥提供商(客户端、设备端)和通行密钥身份验证提供商(服务器端,例如集成到应用中的 Corbado)。
  • 第一方通行密钥提供商是诸如 iCloud 钥匙串和 Google 密码管理器之类的操作系统原生系统;第三方提供商是通过平台 API 集成的密码管理器。
  • 每个通行密钥提供商在凭据数据中都嵌入了一个唯一的 AAGUID(Authenticator Attestation Globally Unique Identifier,验证器证明全局唯一标识符),允许依赖方在账户设置中识别和标记通行密钥。
  • WebAuthn 的 excludeCredentials 选项可以防止用户为同一个提供商注册多个通行密钥,从而减少混淆并改善账户管理的用户体验。
  • 截至 2024 年 3 月,一些平台不支持证明(attestation),这意味着在这些平台上的 AAGUID 值无法进行加密验证,使用时应谨慎。

1. 简介#

当使用通行密钥或在通行密钥实施领域工作时,有一个组件变得非常重要:通行密钥提供商。然而,尽管它是通行密钥生态系统中的关键部分,许多人对通行密钥提供商只有大致的了解,或者不知道第一方通行密钥提供商第三方通行密钥提供商通行密钥身份验证提供商之间的区别。

PasskeyAssessment Icon

在 15 分钟内获取免费的 passkey 评估。

预约免费咨询

本篇博客文章旨在对此进行阐述。无论您是软件开发人员、产品经理,还是仅仅对最新的 Web 安全知识感到好奇,了解通行密钥提供商的作用和类型都是必不可少的。通过揭开这个话题的面纱,我们希望赋予人们自信理解通行密钥的知识。

2. 什么是通行密钥提供商?#

通行密钥提供商在基于通行密钥的身份验证生态系统中发挥着基础性作用,充当用户设备与依赖方(在线服务)的安全、无缝访问之间的桥梁。但是通行密钥提供商到底是什么,特别是由于没有官方定义并且您会在网上找到不同的解释?

以下定义反映了我们的理解,并不声称是唯一准确的定义。

通行密钥提供商本质上是能够实现通行密钥的创建、管理和使用的任何实体。通过我们的研究,我们确定了可将通行密钥提供商归入的两个主要类别:第一方/第三方通行密钥提供商和通行密钥身份验证提供商。

2.1 第一方和第三方通行密钥提供商#

此类别包括能够在客户端(在用户设备上)生成通行密钥的实体。当通过这些平台创建通行密钥时,它会被安全地管理和存储,通常是在操作系统制造商的云中(例如,iCloud 钥匙串、Google 密码管理器)或在第三方密码管理器中(例如 KeePassXC1PasswordDashlane——请参见下文)。

原生地启用通行密钥创建和管理的操作系统被认为是第一方通行密钥提供商。相反,通过 API 与平台集成的第三方密码管理器被称为第三方通行密钥提供商。

同一个第一方或第三方通行密钥提供商具有相同的验证器证明全局唯一标识符(AAGUID),这有助于改善用户体验(例如,在账户设置中更容易区分通行密钥)。有时它们可能有多个 AAGUID,这些 AAGUID 均属于同一个第一方或第三方通行密钥提供商。

iOS 17.4 设备上的通行密钥提供商

Android 14 设备上的通行密钥提供商

Android 的 Credential Manager API

2.2 通行密钥身份验证提供商#

第二类包括开发人员可以集成到其应用程序中以处理通行密钥管理各个方面的身份验证提供商。因此,这些提供商更多地在服务器端工作(与上述的客户端相比)。该定义还包括诸如 Corbado 之类的解决方案,它们为网站和应用提供以通行密钥为中心的身份验证解决方案。因此,更准确的描述应该将这些通行密钥提供商称为通行密钥身份验证提供商,以区分它们与上述的第一方和第三方通行密钥提供商。

在本博文的后续部分中,我们将根据我们的定义,使用术语“通行密钥提供商”来指代第一方和第三方通行密钥提供商。

3. 通过 AAGUID 识别通行密钥提供商#

随着用户开始在各种依赖方采用通行密钥,如何有效地管理它们成为了一个重大挑战。对于一个账户使用多个通行密钥的用户来说尤其如此,因为对于依赖方来说,为了编辑或删除的目的而区分这些通行密钥可能很复杂。尽管通行密钥提供了便利性和安全性,但是如果用户丢失了他们的其中一个通行密钥,就会存在潜在的问题。幸运的是,他们仍然可以使用备用通行密钥在依赖方上访问其账户。为了帮助用户识别特定的通行密钥,一些资源建议在账户设置中向通行密钥添加元数据,例如创建日期和最后使用日期。此外,建议在创建时使用用户代理(user agents)或客户端提示(client hints)自动命名并分类通行密钥。然而,原生的 AndroidiOS 应用程序以及第三方通行密钥提供商,可能不会使用用户代理,或者它们不添加指示通行密钥是由第三方通行密钥提供商生成的信息。这一限制突显了对改进方法的需求,以帮助用户有效地管理他们的通行密钥,无论平台或提供商是什么。

取自 W3C 的 WebAuthn 规范

为了促进这种通行密钥管理,开发人员可以利用验证器证明全局唯一标识符(AAGUID)。AAGUID 是分配给验证器型号的唯一标识符,而不是其特定实例。它嵌入在公钥凭据的验证器数据内,为依赖方提供了一种识别通行密钥提供商的方法。此功能在帮助用户和依赖方浏览通行密钥环境方面至关重要,确保每个通行密钥都能准确地与其创建源关联。

例如,如果在 Android 设备上使用 Google 密码管理器创建通行密钥,依赖方可以收到一个特定于 Google 密码管理器的 AAGUID。通过引用此 AAGUID,依赖方然后可以相应地标记通行密钥,从而简化用户的管理和识别。此外,依赖方可以通过使用 WebAuthn 服务器选项 excludeCredentials 来防止为同一个通行密钥提供商创建多个通行密钥。这进一步改善了通行密钥的 UX,因为每个通行密钥提供商将只有一个通行密钥,从而避免了用户的困惑。

{ "attestation": "none", "authenticatorSelection": { "residentKey": "preferred", "userVerification": "preferred" }, "challenge": "6V61d0VM5bNTPxWSsrv7YKz0o4awe0ryoDh1V44RPRn6-mBQwv98BTRws6nMrBhEggGn7-tk1bl3YNSwc0oZpA", "excludeCredentials": [ { "id": "1kBn2dmhv5JhuFxqeco1khCBCUBLlWYqZmFtdDujH5pM", "transports": ["internal"], "type": "public-key" } ], "extensions": { "credProps": true }, "pubKeyCredParams": [ { "alg": -7, "type": "public-key" }, { "alg": -257, "type": "public-key" } ], "rp": { "id": "Passkey Demo", "name": "passkeys.eu" }, "user": { "displayName": "Test Name", "id": "ZG1sdVkyVnxe3SFJsYzNR", "name": "Test Name" } }

要使用 AAGUID 确定通行密钥提供商,依赖方可以参考社区维护的 AAGUID 存储库。此存储库提供了必要的映射,以按名称及(潜在的)图标识别通行密钥提供商,从而帮助为通行密钥管理提供更直观的用户界面。不过需要注意的是,一些通行密钥提供商可能会故意使用通用 AAGUID("00000000-0000-0000-0000-0000000000000"),代表未知或通用的提供商。

使用大多数 WebAuthn 库检索 AAGUID 是非常直接的。例如,在服务器端使用 SimpleWebAuthn 时,开发人员可以从注册信息中提取 AAGUID 并将其与已知提供商匹配,从而提升用户更轻松地管理通行密钥的能力(摘自 Google 的“使用 AAGUID 确定通行密钥提供商”)。

// Import a list of AAGUIDs from a JSON file import aaguids from "./aaguids.json" with { type: "json" }; // ... // Use SimpleWebAuthn handy function to verify the registration request. const { verified, registrationInfo } = await verifyRegistrationResponse({ response: credential, expectedChallenge, expectedOrigin, expectedRPID, requireUserVerification: false, }); // ... const { aaguid } = registrationInfo; const provider_name = aaguids[aaguid]?.name || "Unknown";

虽然 AAGUID 为通行密钥管理提供了一个强大的工具,但使用时应谨慎。AAGUID 的完整性取决于证明(attestation)过程,该过程验证通行密钥提供商的真实性。没有有效的证明签名,AAGUID 可能会被操纵。截至 2024 年 3 月,值得注意的是一些平台上的通行密钥不支持证明,这突显了在使用它们时需要仔细考虑。

在下文中,您将找到一个非详尽列表,列出了使用非常常见的通行密钥操作系统版本和浏览器时,适用于 Android 应用、iOS 应用和 Web 应用的第一方和第三方通行密钥提供商:

4. Android、iOS 和 Web 的通行密钥提供商列表#

在下文中,您可以找到一些用于创建/保存通行密钥的第三方通行密钥提供商弹出窗口:

4.1 1Password#

在此处查看完整的 1Password 分析。

4.2 Bitwarden#

4.3 Dashlane#

在此处查看完整的 Dashlane 分析。

4.4 Enpass#

4.5 KeePassXC#

在此处查看完整的 KeePassXC 分析。

4.6 Keeper#

4.7 NordPass#

4.8 Proton#

5. 结论#

通行密钥提供商在通行密钥的部署和管理中处于核心地位,这些实体不仅促进了通行密钥的创建和管理,而且还确保了它们在各种平台和设备上的无缝集成。

理解什么是通行密钥提供商,包括第一方和第三方提供商之间的区别,以及验证器证明全局唯一标识符(AAGUID)的关键作用,是本博文的目标。如前所述,AAGUID 的使用提供了一种有前途的解决方案,使通行密钥的识别和管理变得更加直接。

此外,我们分析了目前适用于 Android、iOS 和 Windows 的第一方和第三方通行密钥提供商,这也帮助用户找到合适的第三方通行密钥提供商或他们首选的设备。

对于开发人员和产品经理来说,对通行密钥提供商及其管理的深入了解不仅指导了通行密钥身份验证的技术实施,而且还与提升用户体验和安全性的更广泛目标相一致。

Corbado

关于 Corbado

Corbado 是面向大规模运行 consumer 身份验证的 CIAM 团队的Passkey Intelligence Platform。我们让你看到 IDP 日志和通用 analytics 工具看不到的内容:哪些设备、操作系统版本、浏览器和 credential manager 支持 passkey,为什么注册没有转化为登录,WebAuthn 流程在哪里失败,以及什么时候操作系统或浏览器更新会悄悄破坏登录 — 而且无需替换 Okta、Auth0、Ping、Cognito 或你自有的 IDP。两款产品:Corbado Observe 提供 针对 passkey 及任何其他登录方式的 observability。Corbado Connect 提供 内置 analytics 的 managed passkey(与你的 IDP 并存)。VicRoads 通过 Corbado 为 500 万以上用户运行 passkey(passkey 激活率 +80%)。 与 Passkey 专家交谈

看清你的 passkey 推广中真实发生了什么。

探索 Console

分享本文


LinkedInTwitterFacebook