企业级单点登录SSO：核心架构、原理与登录流程详解

单点登录（Single Sign-On，简称 SSO）是现代企业级应用中实现统一身份认证的关键技术，它允许用户在一次登录后，即可访问所有相互信任的应用系统。

想象一下，当你在使用阿里生态的产品时，可能需要分别登录淘宝、天猫、支付宝和钉钉，这无疑非常繁琐。而通过 SSO，你只需在其中一个产品（例如淘宝）完成登录，访问天猫、支付宝等其他应用时，系统便会自动识别你的登录状态，无需重复输入密码。这就是“一次登录，处处通行”的核心价值。

单点登录核心架构

一个标准的 SSO 架构通常包含以下几个核心角色和组件：

为了更直观地理解角色间的交互关系，我们可以用以下简图表示：

┌────────────┐
│  Browser  │
└─────┬──────┘
      │
未登录访问系统A
      │
┌─────▼──────┐
│ System  A   │  CAS Client
└─────┬──────┘
      │ Redirect
┌─────▼──────┐
│  CAS Server │ 认证中心
└─────┬──────┘
      │
┌─────▼──────┐
│ System  B   │  CAS Client
└────────────┘

核心角色详解

1. 认证服务器 (Authentication Server / CAS Server)
这是SSO系统的中枢，负责所有核心认证逻辑，包括：

• 核心认证：处理用户名/密码验证、二次验证（如短信、OTP、MFA多因素认证）。
• 票据管理：生成、验证和管理各类安全票据，例如票据授予票据（TGT）和服务票据（ST）。
• 协议支持：实现并支持主流认证协议，如CAS协议、SAML、OAuth 2.0 / OpenID Connect等。
• 单点登出协调：管理全局会话，并在用户登出时通知所有已登录的客户端应用。

2. 服务提供方 / 客户端 (Service Providers / Clients)
指需要接入SSO的各个业务应用，例如上述的淘宝、天猫等。它们负责：

• 访问拦截与重定向：当检测到用户未登录时，将请求重定向至认证服务器。
• 票据验证：接收认证服务器颁发的服务票据（ST），并在后台与认证服务器通信以验证其有效性。
• 本地会话管理：票据验证通过后，在应用内为用户创建本地会话（Session），并映射相应的用户身份与权限。

3. 浏览器 (Browser)
作为用户交互的载体，浏览器在不同应用（不同域名）间跳转，并通过认证服务器域下设置的Cookie来维持统一的全局登录状态。

辅助组件

为了支撑高可用、高性能和安全的SSO服务，通常还需要以下组件：

• 反向代理/负载均衡：用于实现认证服务器集群的高可用与流量分发。
• 缓存与会话存储：使用如 Redis 等高性能缓存中间件来存储票据或会话映射信息，显著提升验证性能和系统扩展性。
• 日志与审计系统：记录所有的认证事件、操作日志和异常信息，满足安全合规要求。
• MFA/安全扩展服务：集成多因素认证等服务，进一步增强账户安全性。

单点登录核心流程解析

一个完整的SSO登录流程，可以清晰地分为前台（浏览器）跳转和后台（服务间）验证两部分。

让我们以一个典型场景为例，详细拆解其步骤：

1. 访问受保护应用：用户首次尝试访问应用A（appA.com）。应用A检查本地会话（Session），发现用户未登录，于是拦截该请求。
2. 重定向至认证中心：应用A将用户的浏览器重定向到认证服务器（CAS Server）的登录地址，并携带自己的地址作为回调参数，例如：cas.com/login?service=appA.com。
3. 用户登录认证：浏览器跳转到认证服务器的统一登录页面。用户在此页面输入用户名和密码等凭证进行身份验证。
4. 创建全局会话凭证：认证服务器验证用户凭证成功后，会在服务器端创建一个全局会话，并生成一个代表此次登录的票据授予票据（TGT）。同时，在用户的浏览器中为认证服务器的域名（cas.com）设置一个Cookie，其中包含TGT的标识，以此建立全局登录状态。
5. 颁发服务票据并回调：认证服务器生成一个一次性的、针对应用A的服务票据（ST），然后将浏览器重定向回最初请求的应用A地址，并附上这个ST：appA.com?ticket=ST-xxxxxx。
6. 后台验证服务票据：应用A的后端服务接收到ST后，不会信任前端传来的票据，而是通过一个后台的安全通道（Server-to-Server）向认证服务器发起请求，验证此ST的有效性。
7. 建立局部会话：认证服务器验证ST有效后，会返回该ST对应的用户信息（如用户ID、用户名等）。应用A据此在本地创建该用户的会话（局部Session），并设置自己的Cookie。至此，用户成功登录应用A。
8. 访问其他应用：当用户在同一浏览器中访问另一个已接入SSO的应用B（appB.com）时，应用B同样因检测到无本地会话而将用户重定向至认证服务器。此时，浏览器携带了之前在cas.com域下的Cookie（内含TGT）。认证服务器发现用户已全局登录，便会直接为应用B生成新的ST并跳转回去，重复步骤6-7，用户无需再次输入密码即可登录应用B。

这种架构与流程设计，尤其适合 分布式系统 和微服务场景，它有效地解决了多个独立系统间的身份统一与状态共享难题，在提升用户体验的同时，也简化了系统的权限管理与维护成本。

对于希望深入了解 系统架构 设计、微服务安全等话题的开发者，可以关注 云栈社区 上的更多技术讨论与分享。