互联网大厂如何做单点登录？SSO实现原理及流程详解

在互联网大厂的高并发、分布式架构中，单点登录（Single Sign-On, SSO）不仅是提升用户体验的关键技术，更是保障系统安全与统一身份管理的核心基础设施，大厂通常不会从零开始造轮子，而是基于成熟的协议（如 OAuth 2.0、OIDC、SAML）结合自研或开源组件（如 CAS、Keycloak、Authing 等）构建高度可扩展的 SSO 体系。

核心架构设计原则

大厂 SSO 架构通常遵循“认证与授权分离”、“无状态化”以及“高可用”三大原则。

1. 统一身份中心：所有业务系统不再独立管理用户凭证，而是将认证逻辑收敛到一个统一的身份认证中心（Identity Provider, IdP）。
2. 信任传递：业务系统作为服务提供者（Service Provider, SP），通过标准协议向 IdP 发起认证请求，并信任 IdP 返回的身份断言。
3. Token 化：摒弃传统的 Session 共享方案，广泛采用 JWT（JSON Web Token）或 Access Token + Refresh Token 机制，实现跨域、跨端的无状态认证。

主流协议选型对比

大厂在不同场景下会选择不同的协议,以下是常见协议的对比分析：

典型 SSO 登录流程详解

以目前大厂最主流的 OIDC + JWT 模式为例，一次完整的单点登录过程通常包含以下步骤：

1. 用户访问业务系统：用户尝试访问受保护的资源（如某业务后台），业务系统检测到用户未登录，生成一个包含 client_id、redirect_uri 和 state（防 CSRF 攻破）的认证请求 URL。
2. 重定向至认证中心：浏览器被重定向到统一认证中心（IdP）。
3. 身份验证：
   • 若用户已在 IdP 登录，IdP 验证 Session 有效性。
   • 若未登录,IdP 展示登录页，用户输入账号密码（或进行 MFA 多因素认证）。
4. 颁发 Token：验证通过后，IdP 生成 ID Token（包含用户基本信息）和 Access Token（用于调用 API），并通过回调 URL 将 Token 返回给业务系统（通常通过前端哈希或后端代码交换）。
5. 业务系统验证：业务系统使用公钥验证 Token 签名，解析出用户身份，建立本地会话或直接将 Token 存入前端存储（如 HttpOnly Cookie 或 LocalStorage）。
6. 访问资源

   ：后续请求中，业务系统携带 Token 访问后端 API，后端通过验证 Token 合法性来确认用户身份。

   大厂关键技术难点与解决方案

   跨域与 Cookie 限制

   现代浏览器对第三方 Cookie 的限制日益严格（如 Safari 的 ITP、Chrome 的 SameSite 策略）。

   

   • 解决方案：
     • 后端代理模式：认证中心与业务系统通过后端接口交互，避免前端跨域问题。
     • Token 存储策略：敏感操作使用 HttpOnly Cookie 存储 Access Token，非敏感场景使用 LocalStorage。
     • PostMessage 通信：在 iframe 嵌套场景下，利用 window.postMessage 在认证中心 iframe 和业务系统主页面之间安全传递 Token。

   高并发与性能优化

   登录是高频操作,认证中心必须承受每秒数万次的请求。

   • 解决方案：
     • 多级缓存：在网关层、应用层和 Redis 集群中缓存用户会话状态和 Token 黑名单。
     • 异步化：登录成功后的日志记录、风控检查、消息推送等非核心逻辑采用消息队列异步处理。
     • 无状态设计：JWT 自包含签名信息，后端无需查询数据库验证 Token，极大降低数据库压力。

   安全性加固

   • 防重放攻破：Token 设置短有效期（如 Access Token 15 分钟），配合 Refresh Token 机制。
   • 防 CSRF/XSS：严格设置 Cookie 的 Secure、HttpOnly、SameSite 属性；前端严格过滤输出，防止 XSS 窃取 Token。
   • 动态签名：使用非对称加密（RS256/ES256），私钥由 IdP 保管，公钥公开，确保 Token 不可杜撰。

   统一权限管理（RBAC/ABAC）

   SSO 解决的是“你是谁”的问题，大厂通常在此基础上叠加权限系统：

   • RBAC（基于角色的访问控制）

     

     ：用户 -> 角色 -> 权限，适用于大多数内部管理系统。

   • ABAC（基于属性的访问控制）：根据用户属性、资源属性、环境上下文动态决定权限，适用于复杂的多租户 SaaS 平台。

   相关问题与解答

   Q1: 在大厂架构中，如果认证中心（IdP）宕机，会导致所有业务系统无法登录吗？如何设计容灾？

   A: 是的，IdP 完全不可用，新用户的登录请求将无法完成，但大厂通常通过以下设计将影响降至最低：

   1. 多活部署：IdP 采用多地域多可用区部署，具备自动故障转移能力。
   2. Token 本地验证：由于采用 JWT 无状态设计，只要 Token 未过期且签名有效，业务系统后端无需请求 IdP 即可验证用户身份，IdP 宕机主要影响的是“新登录”和“Token 刷新”，已登录用户的正常业务操作不受影响。
   3. 降级策略：对于核心业务，可配置本地缓存的“最后已知有效用户列表”或允许特定管理员账号通过备用通道登录。

   Q2: 为什么大厂倾向于使用 OIDC 而不是传统的 Session 共享方案？

   A: 主要基于以下三个原因：

   1. 解耦与扩展性：Session 共享需要所有微服务共享同一个 Session 存储（如 Redis），这在微服务拆分后会导致耦合度高、运维复杂，OIDC 的无状态特性使得每个微服务独立验证 Token，无需共享状态。
   2. 跨端支持：现代应用包含 Web、iOS、Android、小程序等多种客户端，Session 机制主要基于 Cookie，难以在移动端原生应用中使用，OIDC 基于 Token，天然支持所有平台。
   3. 安全性与标准化：OIDC 提供了标准化的 Token 生命周期管理（如 Refresh Token 轮换、Token 撤销），比手动管理 Session 过期时间更安全、更规范。