相关源请求解决的问题
通行密钥与特定的网站相关联,只能用于在为其创建的网站进行登录。
这是由依赖方
ID (RP ID),对于为 example.com 网域创建的通行密钥,它可以是 www.example.com
或 example.com
。
而 RP ID 可防止将通行密钥用作 随时随地进行身份验证,会给以下方面带来问题:
- 拥有多个域名的网站:用户无法使用相同的通行密钥
跨国家/地区特定的网域(例如
example.com
和example.co.uk
)。 - 品牌网域:用户无法针对各个网域使用相同的凭据
同一品牌使用的不同网域(例如
acme.com
和acmerewards.com
)。 - 移动应用:移动应用通常没有自己的网域,因此 凭据管理颇具挑战性。
有一些基于身份联合的解决方法,还有一些基于身份联合的解决方法 但在某些情况下使用起来很不方便。相关源请求优惠 解决方案。
解决方案
包含 相关源请求、 网站可以指定允许使用其 RP ID 的来源。
这样一来,用户便有可能在您运营的多个网站上重复使用相同的通行密钥。
要使用相关源请求,您需要在
特定网址 https://{RP ID}/.well-known/webauthn
。如果example.com
想
允许其他源将其用作 RP ID,它应提供以下
文件 (https://example.com/.well-known/webauthn:
)
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
下次其中任何网站发出通行密钥创建请求时
(navigator.credentials.create
) 或身份验证 (navigator.credentials.get
)
使用 example.com
作为 RP ID 时,浏览器会发现一个 RP ID,
与发出请求的来源不匹配。如果浏览器支持 Related Origin
请求,它首先查找
位于 https://{RP ID}/.well-known/webauthn
的 webauthn
文件。如果文件存在
浏览器会检查发出请求的来源是否
文件。如果是,它会继续执行通行密钥创建或身份验证步骤。
如果浏览器不支持相关源请求,则会抛出 SecurityError
。
浏览器支持
- Chrome:从 Chrome 开始支持 128。
- Safari:从 macOS 15 Beta 3 开始支持,在移动设备的 iOS 18 Beta 3 中也受支持。
- Firefox: 等待位置。
如何设置相关源请求
以下演示使用 https://ror-1.glitch.me
和 https://ror-2.glitch.me
这两个网站的示例。
为了让用户能够在这两个网站上使用同一通行密钥登录,它会使用“相关源请求”来允许 ror-2.glitch.me
将 ror-1.glitch.me
用作其 RP ID。
演示
https://ror-2.glitch.me 实现相关源请求以将 ror-1.glitch.me 用作 RP ID,因此 ror-1
和 ror-2
在创建通行密钥或通过通行密钥进行身份验证后,都会将 ror-1.glitch.me
用作 RP ID。
我们还在这些网站上实现了通行密钥数据库共享。
观察以下用户体验:
- 您可以在
ror-2
上成功创建通行密钥并使用该通行密钥进行身份验证,即使该通行密钥的 RP ID 是ror-1
(而非ror-2
)。 - 在
ror-1
或ror-2
上创建通行密钥后,您可以在ror-1
和ror-2
上使用该通行密钥进行身份验证。由于ror-2
将ror-1
指定为 RP ID,因此从其中任何网站发出通行密钥创建或身份验证请求与在 ror-1 上发出请求相同。只有 RP ID 可将请求与源相关联。 - 您在
ror-1
或ror-2
上创建通行密钥后,Chrome 便会在ror-1
和ror-2
上自动填充该通行密钥。 - 在任一网站上创建的凭据的 RP ID 为
ror-1
。
![Chrome 会自动填充这两个网站上的内容。](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=zh-cn)
查看代码:
。第 1 步:实现共享账号数据库
如果您希望用户能够跨各个国家/地区使用相同的通行密钥登录
site-1
和 site-2
,请实现在这些账号之间共享的账号数据库
两个网站
第 2 步:在 site-1 中设置 .well-known/webauthn JSON 文件
首先,配置 site-1.com
,以允许 site-2.com
将其用作
RP ID。为此,请创建 webauthn JSON 文件:
{
"origins": [
"https://site-2.com"
]
}
JSON 对象必须包含名为“origins”的键,其值为 1 的数组 或更多包含网络源的字符串。
重要限制:最多 5 个标签
系统会处理此列表中的每个元素,以提取 eTLD + 1 个标签。
例如,example.co.uk
和 example.de
的 eTLD + 1 标签
example
。但 example-rewards.com
的 eTLD + 1 标签为 example-rewards
。
Chrome 中的标签数量上限为 5 个。
第 3 步:在 site-1 中提供 .well-known/webauthn JSON
然后,在 site-1.com/.well-known/webauthn
下提供 JSON 文件。
例如,简而言之:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
在这里,我们使用的是 Express res.json
,它已将
正确的 content-type
('application/json'
);
第 4 步:在 site-2 中指定所需的 RP ID
在 site-2
代码库中,在任何需要的位置将 site-1.com
设置为 RP ID:
- 创建凭据时:
<ph type="x-smartling-placeholder">
- </ph>
- 在创建凭据时将
site-1.com
设置为 RP ID 传递给navigator.credentials.create
的options
前端调用,通常在服务器端生成。 - 在运行凭据时,将
site-1.com
设置为预期的 RP ID 然后再将其保存到数据库。
- 在创建凭据时将
- 在进行身份验证时:
<ph type="x-smartling-placeholder">
- </ph>
- 将
site-1.com
设置为身份验证options
中的 RP ID 传递给navigator.credentials.get
前端调用;以及 通常是在服务器端生成的 - 将
site-1.com
设置为要在 因此您在验证用户身份之前需要运行凭据验证。
- 将
问题排查
<ph type="x-smartling-placeholder">![Chrome 中的弹出式错误消息。](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=zh-cn)
![Chrome 中的弹出式错误消息。](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=zh-cn)
其他注意事项
在网站和移动应用之间共享通行密钥
借助相关源请求,您的用户可以在多个 网站。 若要允许用户在网站和移动应用中重复使用通行密钥,请按以下步骤操作: 使用以下技巧:
- 在 Chrome 中:Digital Asset 链接。如需了解详情,请访问: 添加对 Digital Asset Links 的支持。
- 在 Safari 中: 关联的网域。
跨网站共享密码
相关源请求可让您的用户跨网站重复使用通行密钥。 跨网站共享密码的解决方案因密码管理工具而异。 对于 Google 密码管理工具,请使用 Digital Asset Links 。 Safari 使用的是其他系统。
凭据管理器和用户代理的角色
这超出了您作为网站开发者的职责范围,但请注意, 术语,RP ID 不应是用户代理或 凭据管理器。用户代理和凭据 管理员应向用户显示使用其凭据的位置。此更改 需要一些时间来实现。临时解决方法是同时显示 当前网站和原始注册网站。