上一篇我们讲了：
《企业认证与安全体系（八）：企业为什么都在用 RBAC？一篇讲透权限模型设计》
到这里，我们已经把认证和授权的核心内容串起来了：
双 Token Token + Redis JWT Spring Security Gateway OAuth2 RBAC前面几篇主要解决的是：
用户怎么登录？ 登录态怎么维护？ 接口怎么鉴权？ 权限怎么控制？但是企业系统里还有一个非常常见的问题：
公司有很多系统，用户难道每个系统都要登录一次吗？
例如一个企业内部可能有：
OA 系统 CRM 系统 ERP 系统 财务系统 工单系统 审批系统 数据报表系统如果每个系统都有一套自己的登录页面、账号密码、登录态维护逻辑，那用户体验会很差，系统维护也会很混乱。
于是，企业里就出现了一个非常重要的能力：
SSO，单点登录。
今天我们就从工程视角讲透：
单点登录 SSO 到底是怎么实现的？
一、先说结论
SSO，全称是：
Single Sign-On中文叫：
单点登录它解决的核心问题是：
用户只需要登录一次，就可以访问多个相互信任的系统。
例如：
用户登录统一认证中心 ↓ 访问 OA 系统 ↓ 访问 CRM 系统 ↓ 访问 ERP 系统 ↓ 都不需要重复登录所以 SSO 的核心不是“怎么生成 Token”。
而是：
多个系统如何共享同一个登录状态。
二、为什么企业需要 SSO？
如果没有 SSO，每个系统都自己做登录。
例如：
OA 系统有一套登录 CRM 系统有一套登录 ERP 系统有一套登录 财务系统有一套登录这会带来很多问题。
1. 用户体验差
用户每天上班可能需要打开多个系统。
如果每个系统都要登录一次：
登录 OA 登录 CRM 登录 ERP 登录财务系统体验非常差。
2. 账号体系混乱
每个系统都维护自己的用户表。
时间久了就会出现：
OA 里有张三 CRM 里也有张三 ERP 里还有一个张三但这些账号是不是同一个人？
密码是不是一致？
离职后是不是都禁用了？
这些都会变得很麻烦。
3. 安全风险高
如果员工离职，只在 OA 系统禁用了账号，但 CRM 或 ERP 还没禁用，就会出现安全隐患。
企业希望做到：
一个地方禁用 所有系统立即失效这就需要统一身份认证。
4. 系统重复建设
如果每个系统都自己实现：
登录 密码加密 Token 生成 Token 刷新 权限校验 账号禁用 密码重置就会大量重复建设。
所以企业通常会把这些能力抽出来，形成统一认证中心。
三、SSO 的本质是什么？
SSO 的本质是：
把登录能力从各个业务系统中抽离出来，交给统一认证中心。
也就是说：
业务系统不再自己处理登录 而是统一跳转到认证中心登录认证中心负责：
用户登录 身份校验 Token 签发 登录态维护 统一退出 账号禁用业务系统负责：
接收认证结果 识别当前用户 执行业务逻辑这样整个体系就清晰了。
用户 ↓ 统一认证中心 ↓ 业务系统 A ↓ 业务系统 B ↓ 业务系统 C四、普通登录和 SSO 有什么区别？
普通登录是：
用户登录系统 A 系统 A 自己校验账号密码 系统 A 自己生成登录态如果用户访问系统 B，还要再登录一次。
而 SSO 是：
用户访问系统 A 系统 A 发现用户未登录 跳转到统一认证中心 用户在认证中心登录 认证中心返回登录结果 系统 A 建立登录态 用户再访问系统 B 系统 B 发现用户未登录 跳转到认证中心 认证中心发现用户已经登录 直接返回登录结果 系统 B 建立登录态用户感受到的是：
我只登录了一次 后面访问其他系统都自动登录了这就是单点登录。
五、SSO 的核心角色
一个典型 SSO 系统一般包含三个角色。
| 角色 | 含义 |
|---|---|
| 用户 | 使用系统的人 |
| 认证中心 | 统一登录平台 |
| 业务系统 | OA、CRM、ERP 等具体系统 |
例如：
用户 ↓ 认证中心 ↓ OA 系统 ↓ CRM 系统 ↓ ERP 系统认证中心是整个 SSO 的核心。
业务系统不再直接处理用户名密码，而是信任认证中心的认证结果。
六、SSO 的典型流程
我们用一个例子来讲。
假设用户要访问 OA 系统。
1. 用户访问 OA 系统
用户访问 oa.company.comOA 系统发现：
当前用户未登录于是跳转到统一认证中心：
auth.company.com2. 用户在认证中心登录
认证中心展示登录页面。
用户输入：
账号 密码 验证码认证中心校验成功后，建立自己的登录态。
例如：
SSO_SESSION这个登录态保存在认证中心域名下。
3. 认证中心返回登录结果
认证中心会把用户带回 OA 系统。
同时返回一个认证结果。
常见方式是返回一个临时 code：
https://oa.company.com/callback?code=abc123OA 系统拿到 code 后，向认证中心换取用户信息或 Token。
4. OA 系统建立自己的登录态
OA 系统拿到用户信息后，建立自己的登录态。
例如：
OA_TOKEN或者生成自己系统内的 JWT。
此时用户就可以正常访问 OA 系统。
5. 用户访问 CRM 系统
用户接着访问：
crm.company.comCRM 系统发现用户未登录，也跳转认证中心。
但认证中心发现：
用户已经在认证中心登录过于是不用再让用户输入账号密码，而是直接返回认证结果给 CRM。
CRM 再建立自己的登录态。
这就是：
一次登录，多系统访问。
七、为什么 SSO 需要认证中心？
SSO 最关键的设计就是认证中心。
因为多个系统之间不应该互相保存用户密码。
例如：
OA 不应该知道用户在 CRM 的登录状态 CRM 不应该知道用户在 ERP 的登录状态 ERP 不应该保存所有系统的密码逻辑所以需要一个统一可信的地方：
认证中心所有业务系统都信任认证中心。
业务系统只关心：
认证中心说这个用户是谁 这个用户是否已经登录不关心账号密码具体怎么校验。
这就是 SSO 的核心架构思想。
八、SSO 和 Cookie 的关系
在 Web 场景下，SSO 很多时候离不开 Cookie。
因为浏览器访问认证中心后，认证中心可以在自己的域名下写入 Cookie。
例如：
auth.company.com写入：
SSO_SESSION=xxxx下次任何业务系统跳转到：
auth.company.com浏览器都会自动带上这个 Cookie。
认证中心就知道：
这个用户已经登录过于是可以直接返回认证结果。
所以在传统 Web SSO 中，Cookie 是实现单点登录体验的重要基础。
九、跨域系统怎么共享登录态？
很多人会问：
OA 是：
oa.company.comCRM 是：
crm.company.com认证中心是：
auth.company.com它们是不同系统，怎么共享登录态？
关键点是：
业务系统之间不是直接共享 Cookie，而是都通过认证中心确认登录状态。
流程是：
OA 未登录 ↓ 跳转 auth.company.com ↓ 认证中心判断用户是否登录 ↓ 返回认证结果给 OA CRM 未登录 ↓ 跳转 auth.company.com ↓ 认证中心判断用户是否登录 ↓ 返回认证结果给 CRM所以不是 OA 把登录态直接给 CRM。
而是：
所有系统都信任认证中心这才是 SSO 的核心。
十、SSO 和 OAuth2 是什么关系？
SSO 是一种登录体验和系统架构目标。
OAuth2 是一种授权协议。
它们不是同一个东西。
但是在现代企业系统中，SSO 经常会基于 OAuth2 / OIDC 实现。
可以这样理解：
| 名称 | 解决的问题 |
|---|---|
| SSO | 登录一次，访问多个系统 |
| OAuth2 | 第三方授权流程 |
| OIDC | 基于 OAuth2 的身份认证协议 |
更准确地说：
OAuth2 更偏授权，OIDC 更偏登录认证。
如果企业要实现现代化统一登录，一般会使用：
OAuth2 + OIDC来完成身份认证和授权流程。
例如：
用户访问业务系统 ↓ 跳转认证中心 ↓ 认证中心完成登录 ↓ 返回 authorization code ↓ 业务系统换取 id_token / access_token ↓ 业务系统识别用户身份这里的id_token通常用于表达用户身份。
这就是 OIDC 在 SSO 中的作用。
十一、SSO 和 JWT 是什么关系？
JWT 不是 SSO。
JWT 只是一种 Token 格式。
SSO 是一种登录体系。
但是 SSO 系统中可以使用 JWT。
例如：
认证中心登录成功后，可以签发：
id_token access_token refresh_token这些 Token 可以是 JWT 格式。
业务系统拿到 JWT 后，可以解析用户身份。
所以关系是：
SSO 是体系 JWT 是 Token 格式 OAuth2 / OIDC 是协议流程不要把它们混为一谈。
十二、SSO 和 Gateway 是什么关系？
Gateway 负责统一入口和统一鉴权。
SSO 负责统一登录。
它们的关系可以这样理解：
SSO：解决用户在哪里登录 Gateway：解决请求进入系统时怎么鉴权在微服务架构里，常见流程是：
用户先通过 SSO 登录 ↓ 拿到 Token ↓ 请求业务接口 ↓ 请求进入 Gateway ↓ Gateway 校验 Token ↓ 转发到后端服务所以 SSO 和 Gateway 是协同关系。
SSO 负责签发身份结果。
Gateway 负责在请求入口校验身份结果。
十三、SSO 和 Redis 是什么关系？
Redis 在 SSO 中常用来保存登录态、Token、会话信息。
例如：
sso:session:xxxx -> userId refresh:user:1001 -> refreshToken login:user:1001 -> loginStatusRedis 的作用是：
统一管理会话 支持主动失效 支持踢下线 支持统一退出 支持多端控制如果员工离职，管理员可以在认证中心禁用账号，并删除 Redis 中的会话信息。
这样所有系统都会失效。
这就是企业统一认证的价值。
十四、什么是统一退出？
SSO 不仅要支持统一登录，还要支持统一退出。
统一退出的目标是：
用户退出一次 所有系统都退出例如用户登录了：
OA CRM ERP 财务系统如果用户点击退出，理想情况是：
认证中心登录态失效 OA 登录态失效 CRM 登录态失效 ERP 登录态失效 财务系统登录态失效这比单系统退出复杂得多。
因为每个业务系统可能都有自己的本地登录态。
所以企业系统里，统一退出通常会涉及：
认证中心 Session 失效 Token 黑名单 Redis 删除登录态 通知业务系统清理本地会话 前端清理本地 Token所以 SSO 的难点不只是登录，还有退出和会话生命周期管理。
十五、SSO 的几种常见实现方式
企业中常见的 SSO 实现方式有几类。
1. 基于 Cookie 的 SSO
适合统一域名体系下的 Web 系统。
例如：
oa.company.com crm.company.com auth.company.com优点是浏览器天然支持 Cookie。
缺点是跨端、APP、小程序场景不够友好。
2. 基于 Token 的 SSO
认证中心登录成功后，签发 Token。
业务系统通过 Token 识别用户。
适合：
前后端分离 APP 小程序 微服务这种方式更符合现代应用架构。
3. 基于 OAuth2 / OIDC 的 SSO
这是现代企业系统中更标准的方式。
通过：
Authorization Code AccessToken RefreshToken IdToken完成统一登录和身份传递。
很多企业身份平台、第三方登录、云服务登录都采用类似思路。
4. 基于 CAS 的 SSO
CAS 是比较经典的单点登录方案。
一些老系统、传统企业系统中还会看到。
它的核心也是：
统一认证中心 业务系统信任认证中心只是协议和实现方式不同。
十六、企业统一身份认证平台怎么设计？
一个成熟的企业统一身份认证平台，通常会包含这些能力：
统一登录 统一退出 账号管理 组织架构 角色权限 Token 管理 第三方登录 应用接入管理 登录日志 安全风控它不只是一个登录接口。
而是一个完整的身份平台。
业务系统接入认证中心后，不再自己维护登录逻辑。
而是统一走认证中心。
整体结构类似：
用户 ↓ 认证中心 Auth Center ↓ 应用 A：OA ↓ 应用 B：CRM ↓ 应用 C：ERP ↓ 应用 D：财务系统认证中心负责身份。
业务系统负责业务。
这才是企业级系统更合理的分工。
十七、SSO 在这个系列中的位置
到这里，我们再把前面几篇串起来。
双 Token ↓ Token + Redis ↓ JWT ↓ Spring Security ↓ Gateway ↓ OAuth2 ↓ RBAC ↓ SSO它们之间的关系是：
| 内容 | 解决的问题 |
|---|---|
| 双 Token | 登录态续签 |
| JWT | Token 身份表达 |
| Redis | 会话控制 |
| Spring Security | 认证授权框架 |
| Gateway | 微服务统一鉴权 |
| OAuth2 / OIDC | 授权与统一身份协议 |
| RBAC | 权限模型 |
| SSO | 多系统统一登录 |
SSO 不是替代前面的内容。
它是在前面这些能力之上，解决企业多系统登录问题。
十八、面试怎么回答 SSO？
如果面试官问：
SSO 是什么？可以这样回答：
SSO 是单点登录，核心目标是让用户只登录一次，就可以访问多个相互信任的业务系统。
它的本质是把登录能力从各个业务系统中抽离出来，交给统一认证中心。
业务系统不再自己处理账号密码登录，而是跳转到认证中心完成登录，然后根据认证中心返回的认证结果建立自己的登录态。
在现代企业系统中，SSO 通常会基于 OAuth2 / OIDC、JWT、Redis 等技术实现。
认证中心负责统一登录、Token 签发、会话管理、统一退出和账号禁用。
业务系统负责根据认证结果识别用户并处理业务逻辑。
十九、最终核心理解
SSO 解决的不是单个系统怎么登录。
它解决的是：
多个系统如何共用一套身份认证能力。
普通登录关注的是：
用户如何登录当前系统SSO 关注的是：
用户登录一次 如何访问多个系统它的核心是：
统一认证中心 业务系统信任认证中心 认证结果在多个系统之间传递所以，SSO 是企业认证体系从“单系统登录”走向“多系统统一身份认证”的关键一步。
对于大型企业系统来说，SSO 不是锦上添花，而是基础能力。
下篇预告
下一篇我们继续：
《企业认证与安全体系（十）：一张图看懂企业认证架构——从登录、鉴权到权限控制完整串联》
这是整个系列的收官篇。
我们将把前面九篇全部串起来：
双 Token Token + Redis JWT Spring Security Gateway OAuth2 RBAC SSO最终形成一张完整的企业认证架构图。
真正回答：
企业里的登录认证体系到底是怎么设计的？