身份验证和第三方 cookie

Question

我正在尝试找出实现跨域身份验证的最佳方法。

\n

设想：

\n

作为登录 youtube.com 的用户，当我通过在新的浏览器选项卡中输入域名https://www.google.com来访问 Google.com 时，我的会话将被保留。

\n

问题：

\n

作为开发人员，如何实现安全、面向未来且用户友好的跨域身份验证？

\n

我会用Google和YouTube的例子来解释这个问题。本示例中将演变的各方是：

\n

\n
1. 身份验证服务：accounts.google.com
\n
2. 第一个域名：google.com
\n
3. 第二个域名：youtube.com
\n

\n

可能的解决方案1

\n

使用 SameSite 属性创建Third-Party Cookie将用于身份验证的 SameSite 属性。该 cookie 将用于存储和维护用户跨网站的会话。

\n

例子

\n

\n
1. 用户访问 YouTube.com 并登录。
\n
2. account.google.com 服务发出第三方会话 Cookie，其中 SameSite 设置为非。
\n
3. 当用户访问 Google.com 时，系统会向 account.google.com 发出 Ajax 请求，其中包含步骤 2 中发出的会话 Cookie。
\n
4. account.google.com 将返回用户个人资料，Google.com 将看到他已通过身份验证。
\n

\n

优点：

\n

\n
1. 易于实施，并且只需对网站进行最少的更改。
\n
2. 用户友好，因为体验不需要任何重定向。
\n
3. 安全，因为调用 Auth API 的网站（上例中的 accouts.google.com）可以列为 CORS 策略的一部分。
\n

\n

缺点：

\n

\n

1. 自 2022 年起，大多数浏览器都会阻止此类 Cookie ：

   \n

   1.1 自 13.1 版本起，Safari 中禁止使用第三方 Cookie。

   \n

   1.2 今年，Firefox 引入了 Total Cookie Protection，\xe2\x80\x9 保证在您浏览网页时不会使用 Cookie 来跟踪您的各个站点。\xe2\x80\x9d

   \n

   1.3 Google 计划到 2023 年逐步淘汰第三方 Cookie，并用FLoC取而代之。

   \n
\n

\n

可能的解决方案2

\n

\n
1. 用户访问 YouTube.com。
\n
2. 在呈现 YouTube 之前，用户会被重定向到accounts.google.com 以检查他的身份验证状态，然后他会被重定向到 YouTube.com
\n
3. 用户登录 YouTube.com 时，首先会被重定向到他登录的 account.google.com，然后会被发送回 YouTube.com
\n
4. 当用户访问 Google.com 时，他首先被重定向到accounts.google.com，并发出身份验证 cookie，然后重定向回 google.com。
\n
5. Google.com 使用 cookie 来验证用户身份并加载其个人资料。
\n

\n

优点：

\n

\n
1. 比第一个解决方案需要更多的工作。
\n
2. 安全，因为我们可以使用第一方 cookie 和身份验证服务重定向到的一些域列表。
\n
3. 安全，因为调用 Auth API 的网站（上例中的 accounts.google.com）可以列为 CORS 策略的一部分。
\n

\n

缺点：

\n

\n
1. 用户体验可能会因重定向而受到影响。例如，如果身份验证服务速度很慢。
\n
2. 如果身份验证服务已关闭，则网站将无法工作，因为当用户开始访问并检查身份验证状态时，它们会将其重定向到该网站。
\n
3. 用户注销时需要清除所有网站的所有 cookie。
\n

\n

问题

\n

\n
1. 我对解决方案 1 和 2 的假设是否正确？
\n
2. 是否有另一种推荐的方法来跨多个域共享会话？
\n
3. Azure (OAuth2) 等身份提供商可以解决这个问题吗？如何管理跨多个域的访问和刷新令牌？
\n

\n

Answer 1

解决方案1

正如您所阐明的，跨域解决方案存在阻塞问题。如今，您需要设计托管域名来共享基本域，例如*.example.com您想共享（第一方）cookie。

一个例子是，在 Google 中，您可以在 和 之间导航drive，mail并且calendar无需重定向，因为所有 3 个应用程序都托管在同一父域中。请注意，所涉及的资源非常相似。

解决方案2

这是 OAuth 标准的处理方式。身份提供商 cookie 是第三方的，但当浏览器中存在顶级重定向时，（当前）不会在任何浏览器中删除，因为这充当用户手势。

每个应用程序的重定向导致每个应用程序获得自己的令牌和生命周期以及特定于该应用程序的权限，从安全角度来看，这更干净。

哪个选项？

我可能会为基于 Micro UI 的架构选择选项 1，其中单个应用程序部署为三个技术组件，或者为一小组具有基本相同权限的应用程序选择。

随着软件规模的扩大，选项 2 更易于管理，并且某些应用程序比其他应用程序具有更高的权限。如果您必须向客户解释您的安全性或接受 PEN 测试，效果会更好。

我认为解决方案 1 中的单点注销选项可能更好。不过，它通常被视为次要要求，而如今人们明白这是一个存在技术限制的领域。