有在不同的域系统的几个部分（不是子域）。我需要在所有域的用户进行身份验证后，他在其中任何一个没有任何用户的交互登录。
在过去，我在公共域使用cookie。现在这是不可能的-https://developer.chrome.com/docs/privacy-sandbox/chips/
然后我们使用iframe与LocalStorage和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
- 域尝试使用此令牌进行身份验证
- 如果未通过身份验证，则在登录/注册期间添加此令牌，以便下次自动登录用户
- 在注销期间删除此用户令牌，使其不再有效
这是可怕的用户界面- 2额外的重定向;似乎过于复杂。
可能有一个更好的解决方案，将在现代浏览器中工作？
2条答案
按热度按时间dojqjjoe1#
这个答案分为两部分，第一部分是关于高层设计，第二部分是关于具体的技术问题。
高层设计
有在不同的域系统的几个部分（不是子域）。我需要在所有域的用户进行身份验证后，他在其中任何一个没有任何用户的交互登录。
我将谈论相对于应用程序域/站点的更抽象的概念：
在理想情况下，有多个应用程序，外加一个专用于 * 认证 * 的单独应用程序，更一般地说，专用于 * 身份 * 服务。（顺便说一句，请注意，* 授权 ，即处理可能与特定上下文 * 下的身份（用户） 相关联的特定角色和权限，实际上通常是特定于应用程序的，与身份服务无关。）
我只看到一个防弹解决方案：
是的，虽然重定向不是绝对必要的：您的身份服务可能只是暴露Web服务，单个应用程序代表用户在后台与之交互。但重定向仍然是规范的解决方案，不仅可以避免代码重复，而且特别是在相关的地方，以便在所有应用程序中保持统一的注册/登录/管理帐户体验。
生成新的token，句号。并将其存储在服务器上以供以后使用，特别是 * 验证 *（见下文）。--对不起，我没有参考资料，但我给予它作为安全最佳实践，登录页面上的经过身份验证的用户自动注销（删除cookie和/或任何存储的与登录相关的token吊销）：这使用户流“干净”。
具体来说，一旦用户通过身份验证，从那里获得了他们的auth token，他们将在每个请求中将其提交给任何应用程序：应用程序在这一点上必须做的是 * 验证 * 令牌（这是标准术语，包括解密有效载荷），它将再次通过利用身份服务公开的Web服务来完成。
令牌通常直接在有效载荷中携带身份信息：这个想法是任何特定应用程序都能够唯一识别用户并在需要时进行任何授权的足够信息。
这是可怕的用户界面- 2额外的重定向;似乎过于复杂。
事实上，重定向到登录页面，然后重定向回用户试图访问的页面，是典型的解决方案，特别是如果用户显式地注册/管理自己的帐户和配置文件：如果不需要，例如在内联网上下文中或机器到机器的身份验证中，只需 Package 一个专用的Web服务就足够了。
技术问题
对于架构概述来说，有一个技术问题我应该特别提到，尤其是因为它明确地存在于问题中：
如果登录页面位于与应用程序本身不同的域中，客户端如何将成功登录时生成的令牌转发到任何其他应用程序页面，因此我们会遇到跨域限制。事实上，我们可以解决这个问题的方法有几种，我将快速提到最常见的方法和我能想到的方法：
*CORS和跨域cookie：也许是最干净和最适合我们的目的。https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS这可能有问题的广告拦截器和类似的，因为这些被认为是第三方cookie：另一方面，它听起来并不合理，要求用户添加有关域/域的异常规则的问题，只要他们确实想登录和使用应用程序.
*使用HTTP状态码307重定向，用于将令牌POST回应用程序。https://www.rfc-editor.org/rfc/rfc9110.html#name-307-temporary-redirect https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307我自己对此没有直接经验，但人们，例如在SO上，说浏览器在允许重定向之前会要求用户进行确认，尽管我在官方文档中找不到任何关于此要求的参考[ADD：无论如何，“用户代理 MAY 使用位置字段值进行 * 自动 * 重定向”语句都是允许的。（我强调），重定向 * 可能 * 不是自动的]：但是，如果大多数浏览器都是这样的话，这在我们的场景中可能不是一个好的解决方案，它会导致用户体验不佳。
*返回一个HTML页面，隐藏字段包括token，在一个表单中，然后在页面加载时由JS自动提交。我认为这也是一个可以接受的解决方案，就用户体验而言，它确实与通常的客户端重定向没有太大区别，页面显示“在3，2，1.秒内自动重定向：点击这个链接，如果这不起作用”。潜在的缺点再次是，这将不会与JS禁用工作，另一方面，如上所述，浏览网页与JS禁用的用户当然不是不习惯点击链接或按下提交按钮，以继续。
*在iframe中打开登录页面并使用
window.postMessageAPI跨域交换结果令牌。https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage这一个需要更多的客户端编码，它也有前面提到的所有基于JS的解决方案的限制，但是，在合理期望用户启用JS的情况下，这一个也是一个可行的解决方案，在我的经验中运行得很好。*共享本地存储和类似的实验性功能. https://developer.chrome.com/docs/privacy-sandbox/shared-storage/任何尚未被浏览器广泛支持的“特殊”功能，我认为在这里都是不可行的：一个例外是完全控制使用中的浏览器的上下文，但我认为这是一种正在消失的场景：在我们普遍访问和随时随地工作的时代。
nwlls2ji2#
在我看来，您所描述的内容非常类似于OAuth 2.0授权流，或者可能是Open Id Connect（OIDC）。
与其尝试一个完全自定义的系统，你可能会更好地重组你的系统，以遵循一个开放的Web标准，使你不太可能在未来的变化中出错。
是的，你需要创建自己的身份服务器，它确实涉及重定向 *，但是 * 作为用户和开发人员，在多个系统上使用Microsoft Azure / Azure AD实现，这并不是一个可怕的用户体验。
有许多博客、教程或第三方产品支持这些流程。搜索“OAuth 2”或“Open ID Connect”+您选择的语言/框架将帮助您开始