组织和开发者在将用户从密码迁移到通行密钥时面临着巨大的障碍。虽然通行密钥可提供至关重要的安全升级,但手动创建过程通常会带来不便。在高流量的电子商务环境中,每一秒的犹豫都至关重要,因为任何延迟都可能会中断购买流程,导致用户放弃购物车。此外,保持服务器与用户设备之间的凭据状态同步对于防止登录错误和用户沮丧至关重要。
而 adidas 正是面临着这些挑战。他们的主要目标是消除登录流程中的障碍,并简化网页和应用平台以及设备上的体验。虽然安全性仍然是重中之重,但产品团队专注于使用通行密钥尽可能顺畅地完成注册和登录流程。
为了应对这些挑战,adidas 实施了有条件创建功能,以自动将密码用户升级为通行密钥用户,并使用 Signal API 来保持凭据一致。此外,他们还部署了相关来源请求,以在需要时支持跨网域使用。
成果
adidas 自动创建通行密钥并保持凭据健康状况的策略在采用率和登录可靠性方面都取得了立竿见影的可衡量成效:
- 采用率高:自推出通行密钥登录流程以来,adidas 的总体通行密钥创建率已达到 47%。这包括在注册或登录流程中提示用户选择启用时,用户选择启用以及自动有条件创建。移动设备上的采用率尤其高,转化率为 52%(桌面设备上的转化率为 34%)。
- 使用条件性创建功能加速升级:除了明确提示之外,adidas 还通过在后台无缝升级现有密码用户,在无需用户手动操作的情况下,将通行密钥创建量提高了 8% 。
- 近乎完美的登录可靠性:在发起登录后,通行密钥的成功率超过 99%。与 adidas 过去 70% 的密码成功率相比,这是一项重大的安全升级,因为人为错误(例如拼写错误或忘记凭据)经常会降低密码成功率。
- 减少摩擦和错误:通过部署 Signal API 来自动同步设备和服务器凭据,adidas 成功将
PASSKEY_NOT_FOUND错误保持在登录尝试次数的 0.3% 以下。这有效地消除了孤立通行密钥给用户带来的困扰。
47 %
通行密钥创建率
8 %
使用条件创建功能提升通行密钥创建量
>99 %
发起通行密钥登录流程后的成功率
<0.3 %
孤立通行密钥错误率
adidas 如何解决该问题
下面介绍了 Adidas 如何应对这些挑战:
1. 通过有条件创建加快采用速度
为了帮助用户顺利采用通行密钥,adidas 实现了条件创建。借助此功能,当用户使用密码管理工具中存储的密码登录网站时,网站可以自动创建通行密钥。为确保最高的成功率,系统会在用户成功登录后立即调用该 API,以便系统将密码使用情况识别为最近使用。
const cred = await navigator.credentials.create({
publicKey: options,
mediation: 'conditional' // Enables automatic passkey creation
});
adidas 将此功能与自定义逻辑集成,该逻辑首先验证用户环境。具体来说,系统会检查浏览器是否支持条件创建功能。如果用户在过去 6 个月内已跳过通行密钥创建流程 3 次,系统也会尊重用户偏好,不再显示提示。
如果环境兼容,系统会在用户成功通过身份验证后立即尝试在后台创建通行密钥。这种特定的时间安排可提高满足前提条件的可能性。重要的是,该实现采用“故障开放”理念来处理 WebAuthn 异常,始终优先考虑用户访问。如果浏览器报告 InvalidStateError,表明可能已存在通行密钥,系统会停止后台创建操作,并立即让用户登录。反之,如果出现 NotAllowedError,这意味着未满足自动创建的特定条件,系统会检测到此状态,并引导用户进入“通行密钥收集器”界面,以引导用户完成手动设置流程。通过区分这些技术限制和用户行为,adidas 确保推动通行密钥升级能够提升登录体验,而不是打断登录体验。
2. 使用 Signal API 确保可靠性
当用户在不同设备上管理凭据时,可能会出现不一致的情况。例如,通行密钥可能会从服务器中删除,但仍保留在用户的设备上。为防止因这些“虚假”凭据而导致登录失败,adidas 实现了 Signal API。此 API 可让服务器向通行密钥提供程序发送凭据状态信号。
adidas 使用所有三种可用的 Signal API 方法来保持这种一致性。 adidas 不会猜测要移除哪些凭据,而是将特定的用户生命周期事件映射到相应的 API 调用:
- 注册失败:当在客户端上创建通行密钥但无法在后端注册时,adidas 会使用
signalUnknownCredential立即移除孤立的凭据。 - 无效的登录尝试:如果用户尝试使用已撤消或过时的通行密钥登录,
signalUnknownCredential会向提供方发送信号以隐藏该通行密钥。 - 用户管理:当用户在其账号设置中明确移除通行密钥时,
signalAllAcceptedCredentials会同步许可名单。 这样可确保系统不再提供已删除的通行密钥。 - 账号更新:当用户更改电子邮件地址或用户名时,
signalCurrentUserDetails会更新设备上的元数据以与服务器保持一致。
// Detect authentication failure due to lack of the credential
if (result.status === 404) {
if (PublicKeyCredential.signalUnknownCredential) {
await PublicKeyCredential.signalUnknownCredential({
rpId: "adidas.com",
credentialId: "..." // base64url encoded credential ID
});
}
}
3. 通过相关来源请求和 Digital Asset Links 统一访问权限
为了进一步支持其多市场架构,adidas 实现了相关来源请求。虽然大多数用户都只访问本地市场(例如 adidas.nl),但通过此配置,在不同地区之间切换的用户可以通过定位单个信赖方 ID (adidas.com) 在允许的网域中重复使用通行密钥。
为此,adidas 会在其主要依赖方 ID (RP ID) 网域中托管 webauthn 配置文件。此文件包含一个明确的许可来源列表,其中列出了允许使用 adidas.com 进行通行密钥注册和身份验证的来源。通过定义这些关系,浏览器可以验证在一个区域性网站上创建的通行密钥是否可在另一个区域性网站上使用,从而为全球用户提供顺畅的体验。
// https://www.adidas.com/.well-known/webauthn
{
"origins": [
"https://www.adidas.fi",
"https://www.adidas.nl",
// ... abridged (the full file lists 50+ regional domains)
]
}
重要的是,adidas 还使用数字资产链接在其 Android 移动应用中提供了无缝的通行密钥支持。由于这些应用使用托管在 idp.adidas.com 上的 WebView 进行身份验证,因此需要使用 Digital Asset Links 在 Android 应用和信赖方 ID (adidas.com) 之间建立信任关系。通过此验证,应用可以访问在网站上使用的相同通行密钥,从而在各个平台之间打造顺畅、统一的登录体验。
为了实现此目的,adidas 在其各自的网域上托管了 Digital Asset Links (assetlinks.json) 文件。此文件会公开声明与相应 Android 应用的加密关联。同样,为了支持其 iOS 生态系统,adidas 使用了关联网域。通过托管 apple-app-site-association 文件,他们可以建立安全连接,让其 iOS 应用安全地在 WebView 中使用通行密钥。
// https://www.adidas.fi/.well-known/assetlinks.json
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.adidas.app",
"sha256_cert_fingerprints": [
"B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
"..."
]
}
},
// ... abridged
]
adidas 的下一步计划是什么?
在 adidas.fi 和 adidas.nl 上,自动升级和同步凭据功能已为 adidas 奠定了坚实的基础,到 2026 年 4 月底,adidas 将在所有其他全球市场中部署这种无缝设置。此外,adidas 还在测试即时中介源试用,以探索更顺畅的登录体验。 未来的计划包括让用户直接使用通行密钥创建账号。这样一来,用户就不再需要先通过其他方法注册。该团队还在研究“智能触发”,以便在登录的第二个验证步骤直接调用系统通行密钥对话框。这样一来,当系统高度确信用户在当前设备上拥有通行密钥时,便无需用户额外点击一次。
这对您有何重要意义
只有在用户体验保持顺畅的情况下,向无密码身份验证的转变才能成功。通过实现有条件创建,您可以轻松地将用户从密码迁移到无密码身份验证,而不会打断他们的习惯。通过使用相关来源请求,您可以在网域之间共享这些通行密钥,让用户只需一个通行密钥即可顺畅访问您的整个生态系统。 最后,将此功能与 Signal API 搭配使用可确保您的统一无密码体验保持可靠且无错误。