现代浏览器中的跨站点身份验证，无需第 3 方 cookie

Question

系统有多个部分位于不同的域（而不是子域）。在用户登录任何域后，我需要在所有域中对用户进行身份验证，而无需用户进行任何交互。

以前我在公共域中使用cookie。现在这是不可能的 - https://developer.chrome.com/docs/privacy-sandbox/chips/

然后我们使用带有 LocalStorage 的 iframe 和 postMessage 到父窗口 - https://github.com/zendesk/cross-storage。它最近也停止工作，因为现在不同的域对于公共域有单独的 LocalStorage - https://developer.chrome.com/docs/privacy-sandbox/storage-partitioning/

Chrome 宣布了可能的解决方案：SharedStorage - https://developer.chrome.com/docs/privacy-sandbox/shared-storage/但是：

• 它在 Safari 中不起作用（MacOS 和 iOS 用户对我们很重要）
• 您必须以公司身份申请并注册您的域名（对我们来说不是问题，但对于舞台和开发环境来说不方便）

我只看到一种防弹解决方案：

• 将所有未经授权的用户重定向到公共域
• 公共域生成随机令牌（或者从 cookie/localstorage 中获取（如果存在））并使用此令牌重定向回原始 URL
• 域尝试使用此令牌进行身份验证
• 如果未经过身份验证，则在登录/注册期间添加此令牌，以便下次它将自动登录用户
• 在注销期间删除此用户令牌，使其不再有效

这对于用户来说是糟糕的 UI - 2 个额外的重定向；看起来过于复杂了。

也许有一个更好的解决方案可以在现代浏览器中工作？

Answer 1

系统有多个部分位于不同的域（而不是子域）。 在用户登录任何域后，我需要在所有域中对用户进行身份验证 他们无需用户的任何交互。

我将谈论相对于应用程序域/站点的更抽象概念：

在理想的情况下，有多个应用程序，加上一个专用于“身份验证”以及更普遍的“身份”服务的单独应用程序。 （顺便说一句，请注意，授权，即处理可能与身份（用户）给定特定上下文相关的特定角色和权限，实际上通常是特定于应用程序的，与身份服务无关。） 我只看到一种防弹解决方案：

将所有未经授权的用户重定向到公共域

• 是的，尽管并不严格需要重定向：您的身份服务可能只是公开 Web 服务，并且单个应用程序代表用户在幕后与其进行交互。但重定向仍然是规范的解决方案，不仅是为了避免代码重复，而且特别是在相关的地方，以便任何注册/登录/管理帐户体验在所有应用程序中保持统一。

公共域生成随机令牌（或从 cookie/localstorage 获取） 如果存在）并使用此令牌重定向回原始 URL

• 生成新的代币，句号。并将其存储在服务器上以供以后使用，特别是
验证

。 -- 抱歉，我没有这方面的参考资料，但我在这里将其作为安全最佳实践，即登陆登录页面的经过身份验证的用户会自动注销（删除 cookie 和/或与登录页面关联的任何存储的令牌）登录撤销）：这可以保持用户流程“干净”。

域尝试使用此令牌进行身份验证

• 具体来说，一旦用户通过身份验证，从哪里获得他们的身份验证令牌，他们就会将其与任何应用程序的每个请求一起提交：应用程序此时必须做的是
验证

令牌，它会再次执行此操作通过利用身份服务公开的 Web 服务。

令牌通常直接在有效负载中携带身份信息：这个想法对于任何特定应用程序来说都有足够的信息，能够唯一地识别用户并在需要时继续进行任何授权。

这对于用户来说是糟糕的 UI - 2 个额外的重定向；看起来过于复杂了。

确实，一种重定向是规范的解决方案，特别是当用户明确注册/管理自己的帐户和配置文件时：如果不需要（例如，在内联网上下文中，或在机器到机器身份验证中），只需包装专用的 Web 服务可能就足够了。