security - 如果所有浏览器都将阻止跨站点跟踪，单点登录应该如何工作

Question

越来越多的现代浏览器默认阻止跨站点跟踪。例如，Safari、Firefox、Brave，它们都使用“防止跨站点跟踪”作为默认选项。我分析了我们的用户，发现其中 6% 的用户阻止了跨站点跟踪，并且在授权和刷新令牌方面存在问题。但我相信这个百分比会增长。据消息称，Safari 默认会继续阻止跟踪。

也许，这是一件好事，但它破坏了大多数单点登录实现。

案子

假设，我们有一个大型国际服务，为一个国家/地区提供一个域：site.com, site.ae, site.ru, site.ca, .... 我们的 SSO 服务sso.site.com遵循三个规则：

1. 用户登录 SSO 域一次
2. 一个用户在所有域上都被授权
3. 他的会话不会过期，因为我们会尽可能长时间地保存他的登录状态（当然，直到他有一天退出）。

SSO 很棒。它帮助用户。用户不关心重新授权。它使公司的事情变得更容易，因为只有一种授权服务。而且您不必为新服务想出另一个。

现代 SSO 实现（即 Auth0、stackauth 等）如何实现这一点？

他们将令牌（访问、刷新、JWT，无关紧要）存储在带有 SSO 域的 cookie 中sso.site.com。例如，当用户打开site.ae or site.ca时，他的用户代理向 SSO 发送请求，SSO 检查存储在 cookie 中的凭据，实现它们（如有必要）并发回响应，然后应用程序向另一个请求用户的数据后端等

问题

但是，如果用户代理默认阻止跨站点 cookie，则无法做到这一点。因为site.aeSSOsite.com存在于sso.site.com

在不久的将来，我们可能不会使用 cookie。是的，我们可以使用一系列重定向。试想一下，如果您有数百个域和每个重定向十毫秒！它会降低性能和用户体验。

所以我的问题是，当所有浏览器都阻止跨站点跟踪时，我们如何登录用户并让他们在世界上的许多域上获得授权？

标签： securitycookiesauthorizationsingle-sign-oncross-site

Answer 1

SSO 协议通常不使用跨站点 cookie。Open ID Connect (OIDC) 的典型用例：

• 在对 IdP 域成功进行身份验证后，用户具有身份提供者 (IdP) 会话（通常是浏览器中的 cookie），例如sso.site.com
• 每个 OIDC 应用程序将未经身份验证的用户重定向到 IdP 登录页面，并且 IdP 使用令牌/代码（取决于使用的流程）将浏览器重定向回来（如果 IdP 会话存在或在成功的用户身份验证之后），然后 OIDC 应用程序处理身份验证 cookies/id 令牌/访问令牌/令牌在自己的域上自行刷新

与 IdP 会话类似的方法也使用 SAML SSO 协议。