单点登录（SSO）全景指南：从原理剖析到落地实战

在现代企业架构中，微服务、SaaS 应用和内部系统层出不穷。用户往往需要记住十几套账号密码，每访问一个新系统就要重新登录一次。这不仅用户体验极差，也增加了运维管理的成本和安全风险。

单点登录（Single Sign-On, SSO） 正是为了解决这一痛点而生。它的核心理念是："一次登录，全网通行"。

本文将深入拆解 SSO 的核心原理，对比主流协议（CAS、OAuth2、OIDC、SAML），并提供一套可落地的架构设计方案。

一、什么是单点登录（SSO）？

1. 核心定义

SSO 是一种身份认证方案，允许用户使用一套凭证（用户名/密码、生物特征等）登录一个中心化的认证系统后，即可访问所有互相信任的应用系统，而无需再次输入凭证。

2. 传统会话 vs. SSO 会话

传统模式 ：
- 系统 A 有独立的 Session/Cookie。
- 系统 B 有独立的 Session/Cookie。
- 用户访问 A 需登录，访问 B 需再次登录。
- 缺点：体验割裂，密码管理混乱，注销困难（需分别退出）。
SSO 模式 ：
- 存在一个统一的认证中心（Identity Provider, IdP）。
- 所有业务系统（Service Provider, SP）信任该认证中心。
- 用户只需在认证中心登录一次，访问任何 SP 时，SP 会向认证中心确认用户身份，自动完成登录。

二、核心原理：SSO 是如何工作的？

无论采用哪种协议，SSO 的底层逻辑都依赖于**"票据（Ticket/Token）"**的传递和验证。最经典的流程如下：

场景模型

用户：浏览器端。
认证中心 (SSO Server)：负责统一登录、发证。
应用系统 A/B (Client)：受保护的业务系统。
共享域名/重定向机制：用于跨域传递状态。

标准交互流程（以基于重定向的 Token 模式为例）

用户访问应用 A：
- 用户请求 app-a.com。
- 应用 A 发现本地无有效会话，拦截请求，重定向用户到 sso-server.com/login?redirect=app-a.com。
用户在认证中心登录：
- 用户看到 SSO 服务器的登录页。
- 输入账号密码，SSO 服务器验证通过。
- 关键步骤 ：SSO 服务器生成一个全局会话（Global Session），并创建一个授权码（Authorization Code）或票据（Ticket）。
- SSO 服务器重定向回应用 A：app-a.com/callback?code=xyz123。
应用 A 换取用户信息：
- 应用 A 拿到 code，在后台向 SSO 服务器发起请求：POST /verify?code=xyz123&app_id=A。
- SSO 服务器验证 code 有效性，返回用户信息（如 UserID, Role）和一个访问令牌（Access Token）。
- 应用 A 建立本地会话（Local Session），允许用户访问。
用户访问应用 B（免登过程）：
- 用户点击链接访问 app-b.com。
- 应用 B 发现无本地会话，重定向到 sso-server.com/login?redirect=app-b.com。
- 关键点：此时浏览器携带了 SSO 服务器的全局 Cookie（步骤 2 中建立的）。
- SSO 服务器检测到用户已登录（全局会话有效），无需用户再次输入密码。
- SSO 服务器直接生成新的 code，重定向回 app-b.com/callback?code=abc456。
- 应用 B 拿 code 换 Token，建立本地会话。
- 结果：用户无感知地进入了系统 B。
单点注销（SLO）：
- 用户在任一系统点击"退出"。
- 该系统通知 SSO 服务器销毁全局会话。
- SSO 服务器遍历所有注册过的子系统，发送回调请求，通知它们销毁本地会话。

三、主流协议与方案选型

实现 SSO 有多种协议，选择哪种取决于你的应用场景（内部系统、互联网开放平台、企业间互联）。

协议/方案	全称	特点	适用场景	复杂度
CAS	Central Authentication Service	老牌、简单、基于 Ticket。由耶鲁大学开源。	高校、传统企业内部系统、Java 生态。	⭐⭐
OAuth 2.0	Open Authorization	授权标准，非认证标准。主要用于第三方资源访问授权。	微信/QQ 登录、API 授权。	⭐⭐⭐
OIDC	OpenID Connect	基于 OAuth 2.0 构建的身份认证层。返回 ID Token (JWT)。	现代互联网应用首选，移动端、前后端分离架构。	⭐⭐⭐⭐
SAML 2.0	Security Assertion Markup Language	基于 XML，极其严谨复杂，企业级标准。	跨国大企业、政府机构、遗留系统集成。	⭐⭐⭐⭐⭐
LDAP/AD	Lightweight Directory Access Protocol	目录服务协议，常作为 SSO 的后端数据源。	企业内部员工账号统一管理。	⭐⭐⭐

深度解析：为什么现在推荐 OIDC？

虽然 CAS 很简单，但它在移动端支持和标准化方面略显老旧。SAML 太重且解析 XML 性能较差。 OIDC (OpenID Connect) 是目前业界的事实标准：

基于 JSON 和 JWT：轻量级，易于解析，适合前后端分离。
标准化用户信息 ：定义了标准的 id_token，包含用户身份信息（UserInfo Endpoint）。
生态丰富：Keycloak, Auth0, Okta, Spring Security OAuth2 等主流框架均原生支持。
灵活：支持授权码模式（最安全）、隐式模式（已废弃）、密码模式（不推荐）等。

四、落地实现方案：自研 vs. 集成

方案 A：使用成熟开源产品（强烈推荐）

对于大多数团队，不要重复造轮子。身份安全关乎身家性命，成熟的开源产品经过了全球社区的审计和打磨。

1. Keycloak (RedHat 出品)

特点：功能最全，支持 OIDC, SAML, CAS, LDAP 集成，自带管理控制台，支持社交登录，支持多因素认证（MFA）。
优势：开箱即用，社区活跃，文档丰富。
部署：支持 Docker/K8s 部署。
适用：绝大多数中大型项目。

2. MaxKey / Casdoor

MaxKey：国内开源，对中文支持好，符合国内信创标准。
Casdoor：Go 语言编写，高性能，UI 美观，易于集成。

实施步骤：

部署 Keycloak 服务。
在 Keycloak 创建 Realm（租户），配置用户数据库（或对接 LDAP/AD）。
为每个业务系统创建 Client（客户端），获取 Client-ID 和 Secret。
业务系统引入 SDK（如 spring-boot-starter-oauth2-client），配置 issuer-uri 和 client-id。
代码层面只需添加 @PreAuthorize 等注解即可保护接口。

方案 B：基于 Spring Security 自研（仅限特殊需求）

如果业务极其特殊，无法使用标准产品，可基于 Spring Security + Redis 自研简易 SSO。

核心组件设计：

SSO-Auth-Server ：
- 提供 /login 页面。
- 生成全局 Token (UUID)，存入 Redis (key: sso_token:xxx, value: userId, expire: 2h)。
- 提供 /validate 接口供子系统校验 Token。
业务子系统 Filter ：
- 拦截请求，检查本地 Cookie。
- 无 Cookie 则重定向至 SSO-Auth-Server。
- 接收回调，调用 /validate，成功后写入本地 Cookie。

⚠️ 自研风险：

容易忽略 CSRF 攻击、重放攻击。
单点注销（SLO）逻辑复杂，容易遗漏。
缺乏审计日志和多因素认证支持。
结论：除非为了学习或极度受限的环境，否则生产环境不建议自研核心认证逻辑。

五、关键挑战与解决方案

浏览器的同源策略限制 Cookie 只能在同域下传输。

解决：SSO 服务器通常部署在独立域名（如 sso.example.com）。业务系统通过重定向将用户带到该域名下建立全局 Cookie，然后再重定向回业务域名。这是标准 OIDC/CAS 流程天然解决的，不需要前端手动操作 Cookie。

2. 单点注销（SLO）的可靠性

如何确保用户退出后，所有子系统都退出？

前端 iframe 法（传统）：SSO 服务器返回一个页面，里面包含所有子系统的注销 iframe 链接。但现代浏览器对第三方 Cookie 和 iframe 限制越来越严，此法逐渐失效。
后端回调法（推荐） ：
- 子系统登录时，向 SSO 服务器注册一个"注销回调 URL"。
- 用户注销时，SSO 服务器遍历注册列表，向后端发起 HTTP 请求通知注销。
- 难点：需处理网络超时、子系统宕机。通常采用"最终一致性"策略，配合消息队列（MQ）广播注销事件。

3. 性能与高可用

认证中心是所有流量的入口，一旦挂掉，全公司系统瘫痪。

集群部署：SSO 服务必须多实例部署，前置负载均衡（Nginx/SLB）。
Session 共享：全局会话数据必须存储在外部缓存（Redis Cluster），不能存在内存中。
异地多活：对于超大规模系统，需考虑认证中心的异地容灾。

4. 安全性加固

强制 HTTPS：所有 Token 传输必须加密。
短效 Token：Access Token 有效期设短（如 15 分钟），配合 Refresh Token 机制。
防重放：授权码（Code）只能使用一次，用完即焚。
审计日志：记录所有登录、注销、授权失败的行为。

六、总结与建议

单点登录（SSO）是现代 IT 架构的基础设施。它不仅仅是方便用户少输几次密码，更是企业统一身份治理、提升安全水位的关键一步。

落地建议路线图：

小型项目/初创期：直接使用云厂商提供的身份服务（如 Auth0, 阿里云 IDaaS），零运维成本。
中型项目/成长期 ：私有化部署 Keycloak 或 Casdoor。利用其成熟的 OIDC 协议对接各业务系统。
大型国企/复杂遗留系统：可能需要混合模式。核心新系统用 OIDC，老旧 Java 系统用 CAS，Windows 域环境用 AD/LDAP 联邦。此时 Keycloak 也能作为聚合层（Identity Broker）来统一对接。

最后记住 ：身份认证是安全链条中最脆弱的一环。不要试图自己发明加密算法或认证流程，站在巨人的肩膀上（使用标准协议和成熟产品），才是最高效、最安全的选择。

单点登录（SSO）全景指南：从原理剖析到落地实战