1

这更像是一个哲学问题而不是技术问题，但我认为它仍然具有相关性，即使它更多地归结为 UX 设计而不是其他任何东西。

现在是 2021 年，几乎没有人拥有 Yubikey 或类似设备，但几乎每个人都拥有带有 TPM 和支持 FIDO2 和 WebAuthn 的操作系统或浏览器的手机、平板电脑或台式机/笔记本电脑。因此，我想探索使内置身份验证器注册过程尽可能流畅的方法，并且不要求他们（至少暂时）进行常规密码身份验证以使其完成。

有没有人知道类似于 OpenID Connect 设备流程的野外方法，有人可以去公共注册端点，为他们的设备进行注册仪式，然后使用生成的唯一代码将其链接到另一个已经存在的帐户注册设备？

我会看到它像这样工作：

  1. 用户通过链接或一些说明访问https://idp.mycompany.com/enroll
  2. 他们点击“注册此设备”按钮并触发创建凭证交互（可能需要在此处提示输入用户 ID，因为我们需要它来设置常驻密钥）
  3. 我们将生成的凭证存储在后端并交换一个唯一的代码（例如 ABC123）
  4. 用户在已经注册的设备上访问https://idp.mycompany.com/enroll/ABC123（或者可能访问可以输入代码的 UI）
  5. 提示用户使用其已注册设备上的常驻密钥进行身份验证
  6. 用户登录后，存储的凭据将添加到相关用户帐户中，并且他们会收到视觉确认
  7. 用户可以在新注册的设备上使用凭据登录

这对我来说是非常安全的，因为即使可以猜到一个代码，你可以做的最糟糕的事情就是将其他人的凭据添加到你的帐户中，并且由于这是在经过身份验证的上下文中发生的，因此我们可以轻松地实现速率限制。用户可以在事后自由管理他们的凭据，但他们认为可以通过管理 UI 进行管理。

第 2 步可能是我最不清楚的一点，但我的想法是，用户是否为常驻密钥提供垃圾用户详细信息并不重要，因为无论如何我们都将根据后端的凭证 ID 进行链接。如果他们胡说八道，那么他们只会影响他们自己的用户体验，不会影响其他任何事情，如果他们愿意，他们可以自由地纠正错误。

想法？

附录：经过深思熟虑，我认为这种方法（以及与此相关的 OIDC/OAuth2 设备流程）打开了一个重要的网络钓鱼向量，因此可能应该避免。

4

1 回答 1

2

一般流程是这样的：

  • 服务启用“无密码登录”功能。
  • 下次用户登录时，服务会检查平台验证器是否可用，如果可用，将提示用户“您要启用无密码登录吗？”。
  • 如果用户同意，服务会注册设备凭证（需要 RK）。
  • 在登录期间，用户可以选择使用用户名，在这种情况下，服务将尝试可用的 FIDO 凭据。
  • 或者，用户可以按“无用户名登录”，然后进行RK流程。

代码中当然不需要。

顺便说一句：FIDO 联盟有它自己的 UX/UI 指南，称为“如何 FIDO” https://github.com/fido-alliance/how-to-fido，我强烈建议您看看它。

于 2021-10-04T23:34:54.183 回答