最近接了一个公司的SSO统一身份认证sdk的维护的活。那什么是SSO，能做什么？公司级别的多个不同域名之间的登录态，如何做到可以无感登录呢？
其实不同域名之间的登录态同步是一种常见的需求，尤其是在大型公司拥有多个子域名或业务平台时。以下是几种实现跨域登录态同步的方法，像阿里巴巴旗下的淘宝和天猫这种情况就是一个例子：
1. 统一身份认证（SSO）
单点登录（SSO）是一种常见的跨域登录态共享解决方案。通过 SSO，用户只需登录一次，就可以访问所有相应的应用系统。常见的 SSO 实现方式包括 OAuth、OpenID Connect、SAML 等。
- OAuth/OpenID Connect: 使用授权服务器来管理登录状态和认证。用户在一个域名下登录时，授权服务器发放一个令牌，这个令牌可以在其他域名中验证。
- SAML: Security Assertion Markup Language（SAML）是一个用于身份验证的标准协议。用户在一个服务上登录后，服务会生成一个 SAML 断言，其他服务通过验证这个断言来实现用户登录。
2. 跨域 Cookie 共享
虽然浏览器安全策略不允许跨域直接共享 Cookie，但可以通过以下方法实现跨域 Cookie 共享：
-
主域名下的子域共享 Cookie: 如果不同的子域（如
shop.example.com和store.example.com）都属于同一个主域（如.example.com），可以通过设置 Cookie 的Domain属性为主域（Domain=.example.com），实现跨子域共享。注意这种方式不能跨越完全不同的顶级域名。Set-Cookie: sessionId=abcd1234; Domain=.example.com; Path=/; HttpOnly; Secure -
前端转发令牌: 登录时将令牌存储在主域的 Cookie 中，然后通过重定向或 JavaScript 将令牌传递到其他域名的应用程序。应用程序在接收到令牌后，使用它向认证服务验证用户身份，并设置本域的 Cookie。
直接修改浏览器的 SameSite 和 Secure 值，配置 CORS 来实现跨域 Cookie 共享可能带来一些安全风险。下面是对这些设置的详细说明及其潜在风险：
2.1 SameSite 和 Secure Cookie 属性
SameSite 属性
SameSite=None: 允许跨站点请求发送 Cookie。这对于需要跨域 Cookie 共享的场景是必需的。
SameSite=Strict: 仅在同站点请求中发送 Cookie，跨站请求不会携带 Cookie。SameSite=Lax: 仅在某些情况下（如 GET 请求）发送 Cookie，但跨站点 POST 请求不会发送 Cookie。
Secure 属性
Secure: 仅在 HTTPS 连接中发送 Cookie。这个属性可以防止 Cookie 在不安全的 HTTP 连接中被传输，从而提高安全性。
2.2 配置 CORS（跨源资源共享）
要使跨域请求能够携带 Cookie，需要配置 CORS：
Access-Control-Allow-Origin: 设置为允许的源（例如https://example.com）。
Access-Control-Allow-Credentials: 设置为true，允许跨域请求携带 Cookie。
Access-Control-Allow-Methods: 配置允许的 HTTP 方法（如GET,POST,PUT等）。
Access-Control-Allow-Headers: 配置允许的请求头。
2.3. 安全风险
a. CSRF（跨站请求伪造）
- 描述: 攻击者利用受害者的身份向受害者不知情的第三方网站发起请求，可能会导致未授权的操作。
- 风险: 如果
SameSite属性设置不当，攻击者可能会利用跨站请求伪造攻击来提交恶意请求。
防御措施:
- 使用
SameSite=Strict或SameSite=Lax来限制跨站点请求。 - 实现 CSRF 令牌验证，确保请求的有效性。
b. 会话劫持
- 描述: 攻击者可能通过中间人攻击（MITM）窃取 HTTP 连接中的 Cookie，进而劫持用户会话。
- 风险: 如果
Secure属性未设置，Cookie 可能会在不安全的 HTTP 连接中被传输。
防御措施:
- 确保所有 Cookie 都使用
Secure属性，以仅在 HTTPS 连接中传输。 - 使用加密协议（HTTPS）来保护所有的传输数据。
c. Cookie 泄露
- 描述: Cookie 信息可能会被意外泄露或被攻击者窃取。
- 风险: 不正确的
SameSite或Secure配置可能导致 Cookie 泄露或被恶意使用。
防御措施:
- 确保正确配置
SameSite和Secure属性。 - 定期审计和检查 Cookie 配置，确保其符合最佳安全实践。
d. CORS 配置漏洞
- 描述: 不正确的 CORS 配置可能导致不必要的跨域请求，暴露敏感数据。
- 风险: 如果
Access-Control-Allow-Origin配置不严格，可能会导致恶意网站访问你的 API 或获取敏感数据。
防御措施:
- 精确配置
Access-Control-Allow-Origin，只允许可信的来源。 - 定期审计 CORS 配置，确保其安全性和有效性。
小结
通过直接修改浏览器的
SameSite和Secure设置来实现跨域 Cookie 共享可以带来便利，但也伴随一定的安全风险。你需要确保：
正确设置SameSite和Secure: 限制 Cookie 的传输范围和保护其安全性。
配置 CORS: 确保正确的跨域请求处理，避免敏感数据泄露。
实施额外的安全措施: 如 CSRF 令牌、HTTPS 和其他安全控制，确保整体安全性。
良好的安全实践和定期审计可以帮助减少这些风险。
3. 使用 OAuth2/OpenID Connect
-
OAuth2: 用户登录时，通过 OAuth2 授权服务器获取一个访问令牌（access token）。其他应用可以通过这个令牌来验证用户身份，从而实现跨域登录。
-
OpenID Connect: 基于 OAuth2 扩展的认证层，提供用户身份信息。用户登录后，认证服务器会发放一个 ID 令牌，其他域名可以通过该令牌验证用户身份。
4. API 认证和授权
- 共享 API 认证: 将用户登录信息存储在认证服务器中，应用程序通过调用认证服务器的 API 进行用户验证。各个子域可以共享相同的认证服务器来验证用户的登录状态。
5. Token-based Authentication
- JWT（JSON Web Tokens）: JWT 是一种常用的令牌格式，用于在应用之间传递用户信息。用户登录后，服务器生成一个 JWT 令牌，并将其存储在 Cookie 或本地存储中。不同的应用或域名可以共享这个 JWT，验证用户的身份。
6. 中央化身份管理
- 集中式身份管理系统: 部署一个统一的身份管理系统，通过该系统实现用户的统一登录和身份验证。所有子系统都与这个中央身份管理系统进行交互，从而实现跨域的登录态同步。
实际应用
在阿里巴巴的例子中，淘宝和天猫通过以上某种组合的方式实现登录态共享。通常它们会采用统一的身份认证平台，并可能结合跨域的 Cookie 设置、令牌传递等技术来确保用户在一个平台上登录后，可以无缝访问另一个平台。
总结
不同域名之间的登录态同步可以通过以下几种方法实现：
- 单点登录（SSO）
- 跨域 Cookie 共享（子域名共享）
- OAuth2/OpenID Connect
- API 认证和授权
- Token-based Authentication (JWT)
- 中央化身份管理系统
选择具体的实现方式取决于你的系统架构、安全需求和用户体验目标。
