越来越多的现代浏览器默认阻止跨站点跟踪。例如，Safari，Firefox，Brave，它们都使用"防止跨站点跟踪"作为默认选项。我分析了我们的用户，发现其中 6% 的用户阻止跨站点跟踪，并且在授权和刷新令牌方面存在问题。但我相信这个比例会增长。根据消息，默认情况下，Safari将继续阻止跟踪。
也许，这是一件好事，但它破坏了大多数单点登录实现。
案例
假设我们有一个大型国际服务，一个国家有一个域名：site.com, site.ae, site.ru, site.ca, ...。我们在sso.site.com上提供遵循三条规则的 SSO 服务：
- 用户登录 SSO 域一次
- 用户在所有域中都已获得授权
- 他的会话不会过期，因为我们尽可能长时间地保存他登录状态(当然，直到他有一天退出(。
SSO 很棒。它可以帮助用户。用户不关心重新授权。它使公司的事情变得更容易，因为只有一个授权服务。而且您不必为新服务提出另一个。
现代SSO实现(即Auth0，stackauth e.t.c(如何实现这一点？
他们将令牌(访问、刷新、JWT、无关紧要(存储在带有 SSO 域sso.site.com的 cookie 中。例如，当用户打开site.ae or site.ca时，他的用户代理向 SSO 发送请求，SSO 检查他存储在 cookie 中的凭据，实现它们(如有必要(并发回响应，然后应用程序要求用户的数据到另一个后端 e.t.c。
问题所在
但是，如果用户代理默认阻止跨站点 cookie，则无法做到这一点。导致 SSO cookie 不会从另一个域发送(即site.ae(site.com除外，因为 SSO 存在于sso.site.com
在不久的将来，我们可能不会使用 Cookie。是的，我们可以使用一系列重定向。试想一下，如果您有数百个域，并且每个重定向都有十毫秒！它会降低性能和用户体验。
所以我的问题是，当所有浏览器都阻止跨站点跟踪时，我们如何登录用户并保持他们在世界上许多域上的授权？
SSO 协议通常不使用跨站点 cookie。Open ID Connect (OIDC( 的典型用例：
- 用户在成功对 IdP 域进行身份验证后具有身份提供程序 (IdP( 会话(通常是浏览器中的 cookie(，例如
sso.site.com
每个 OIDC 应用程序 - 将未经身份验证的用户重定向到 IdP 登录页面，IdP 使用令牌/代码(取决于使用的流(将浏览器重定向回(如果 IdP 会话存在或在用户身份验证成功后(，然后 OIDC 应用程序在自己的域上自行处理身份验证 cookie/id 令牌/访问令牌/令牌刷新
与 IdP 会话类似的方法也使用 SAML SSO 协议。