chat
详细展开介绍一下 SSO
在有了 UMS（用户管理系统） 作为统一用户基础之后，下一步自然就是构建 SSO（Single Sign-On，单点登录系统） —— 企业身份体系的“统一认证层”。
这一层是企业内部 所有系统的入口，也是从“多个独立系统”走向“统一身份中台”的关键步骤。
下面我来系统、深入地讲清楚 SSO 的原理、架构、关键模块、协议设计、Token 策略、以及和 UMS/Passport 的关系。
🧩 一、SSO 是什么？（定义与目标）
SSO（Single Sign-On，单点登录） 的核心目标是：
用户在企业任意一个系统中登录一次后，便可以无缝访问公司内其他系统，而无需重复输入用户名和密码。
✅ 简单理解
- 没有 SSO：每个系统都要登录一次。
- 有了 SSO：登录一次，全网通行。
🧭 二、SSO 的核心价值
| 价值方向 | 说明 |
|---|---|
| 💡 用户体验 | 只需登录一次，不重复输入密码 |
| 🔒 安全合规 | 统一身份认证，集中风控、审计、登出 |
| ⚙️ 架构统一 | 各系统通过统一认证标准接入 |
| 🧰 可扩展性 | 支持接入外部系统、第三方身份 |
| 🧠 管理效率 | 集中管理会话、Token、用户状态 |
🧠 三、SSO 的核心思路（原理）
我们从“流程”层面先看：
🧾 单点登录流程（基础版）
- 用户访问子系统 A（如 OA）
- 系统 A 发现用户未登录 → 跳转到 SSO 登录页
- 用户在 SSO 登录页输入账号密码
- SSO 认证成功，生成 Token / Ticket 并写入 Cookie（绑定 SSO 域）
- SSO 重定向回系统 A，并携带授权票据（如
code或ticket） - 系统 A 调用 SSO 的验证接口
/validate，验证成功后建立本地会话 - 后续访问系统 B 时，B 发现同域 Cookie 中已有登录状态 → 直接放行（或用 Token 免密登录）
✅ 效果：登录一次，全系统共享登录态。
🧩 四、SSO 的核心组成模块
一个完整的 SSO 系统通常由以下几个部分组成👇：
1️⃣ 认证中心（Auth Server）
功能：负责统一的登录、注册、密码找回、Token 签发。
| 功能点 | 说明 |
|---|---|
| 登录页（/login） | 用户登录入口 |
| 登出接口（/logout） | 注销全局登录状态 |
| 授权码签发（/authorize） | OAuth2 标准接口 |
| Token 签发（/token） | Access Token、ID Token、Refresh Token |
| 用户信息接口（/userinfo） | 获取当前登录用户信息 |
| 统一会话管理 | 用户登录状态统一缓存（Redis / DB） |
⚙️ 可直接复用：Spring Authorization Server / Keycloak / Auth0。
2️⃣ 应用系统（Client / Service Provider）
功能：依赖 SSO 的系统（如 CRM、OA、Wiki、BI）。
| 关键点 | 说明 |
|---|---|
| 注册为 SSO 客户端（client_id + secret） | |
| 登录时重定向到 SSO 登录页 | |
登录后通过 code → token 完成授权 |
|
| 本地维护短期 Session | |
| 可通过 SDK 验证用户 Token |
3️⃣ Token 管理模块
负责登录凭证的生成、刷新与验证。
| 类型 | 说明 |
|---|---|
| Access Token | 短期访问凭证（通常有效期15~60分钟） |
| Refresh Token | 用于刷新 Access Token |
| ID Token | （OpenID Connect）包含用户身份声明 |
| Session Token / Ticket | Web 场景下绑定 Cookie 的会话凭证 |
⚙️ 建议：
- 后端系统用 JWT（无状态）
- 前端 Web 登录用 Session Ticket（可统一登出）
4️⃣ 单点登出（Single Logout）
SSO 的另一个关键特性：退出一个系统，所有系统都退出。
实现方式：
| 方式 | 说明 |
|---|---|
| 前端方式 | 各系统的 iframe 监听登出事件 |
| 后端方式 | SSO 服务主动调用各系统的 /logout 接口 |
| 混合方式 | 前后端联动触发注销 |
✅ 推荐：后端回调方式更安全可靠。
5️⃣ 会话与安全控制模块
| 功能 | 说明 |
|---|---|
| 会话持久化 | 用户登录状态记录（session_id、client_id、expires） |
| 黑名单机制 | 被登出的 Token 加入黑名单 |
| 并发登录控制 | 限制多终端登录 |
| 审计日志 | 登录日志、设备、IP、时间、结果 |
⚙️ 五、SSO 常用协议与标准
| 协议 | 场景 | 说明 |
|---|---|---|
| OAuth 2.0 | 授权协议 | 常用于应用间授权（API级） |
| OpenID Connect (OIDC) | 基于 OAuth2 扩展的身份认证协议 | 企业 SSO 主流 |
| SAML 2.0 | XML 协议，常用于传统企业系统 | |
| JWT (JSON Web Token) | Token 格式 | 携带身份信息 |
| LDAP / Kerberos | 内网认证 | 老式企业系统常用 |
💡 推荐：现代企业统一采用 OpenID Connect + OAuth2.0 + JWT。
🏗️ 六、SSO 的系统架构
┌────────────────────────────┐
│ 用户浏览器 │
└─────────────┬──────────────┘
│
▼
┌────────────────────┐
│ SSO 认证中心（Auth Server） │
│ - 登录页 (/login) │
│ - 授权码 (/authorize) │
│ - Token (/token) │
│ - 用户信息 (/userinfo) │
│ - 登出 (/logout) │
└───────────┬────────────────┘
│
┌──────────────────────┼────────────────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ 系统A CRM │ │ 系统B OA │ │ 系统C BI │
│ (Client) │ │ (Client) │ │ (Client) │
└────────────┘ └────────────┘ └────────────┘
🔐 七、登录凭证设计（Token 策略）
1️⃣ Token 类型建议
| 类型 | 有效期 | 用途 |
|---|---|---|
| Access Token | 15-60 分钟 | 调接口凭证 |
| Refresh Token | 7-30 天 | 刷新 Access Token |
| ID Token | 同 Access Token | 携带用户信息 |
| Session Cookie | 浏览器短期登录态 | Web 登录维持 |
2️⃣ 签发与验证逻辑
- 签发： SSO Auth Server 生成 JWT，签名（RSA / HMAC）。
- 验证： 各系统通过 SDK 校验 JWT 签名（公钥验证）。
- 刷新： Access Token 过期 → 用 Refresh Token 获取新 Token。
- 撤销： 强制登出时，加入 Token 黑名单。
🧰 八、技术实现选型
| 模块 | 推荐技术栈 |
|---|---|
| 认证服务端 | Spring Authorization Server / Keycloak / OAuth2 Proxy |
| Token 存储 | Redis / DB（短期票据） |
| JWT 签名 | RSA 非对称加密 |
| 登录 UI | Vue / React 独立登录页（统一风格） |
| 客户端集成 | OAuth2 Client SDK / Spring Security OAuth Client |
| 日志审计 | ELK / Loki / Kafka Sink |
🧱 九、与 UMS、Passport 的关系
| 层级 | 职责 | 举例 |
|---|---|---|
| UMS | 用户主数据管理 | 用户、部门、岗位 |
| SSO | 统一认证（登录） | 登录页、Token、单点登出 |
| Passport | 统一授权（权限） | 角色、资源、策略 |
| IAM Gateway | 统一鉴权入口 | API 层安全控制 |
✅ 简单理解：
- UMS：谁（用户）
- SSO：谁登录了
- Passport：能干什么
- IAM Gateway：在什么场景下允许做什么
🧩 十、SSO 实践中的关键设计要点
| 设计点 | 建议 |
|---|---|
| 跨域问题 | 统一二级域名（如 *.corp.com）可共享 Cookie |
| 安全性 | Token 加签、CSRF 防护、登录失败限制 |
| 多端支持 | Web / App / API 一致认证 |
| 登录日志审计 | 记录 IP、设备、系统来源 |
| 企业门户整合 | 登录后跳转统一 Portal 展示所有系统入口 |
| 第三方接入 | 对接钉钉、飞书、企业微信登录 |
| 零信任演进 | 将 SSO 与风控系统结合，基于风险动态验证 |
🚀 十一、典型架构落地路线
| 阶段 | 目标 | 关键成果 |
|---|---|---|
| 1️⃣ | 基础 SSO 实现 | 用户统一登录、登出、Token 机制 |
| 2️⃣ | OAuth2 / OIDC 支持 | 各系统标准接入 |
| 3️⃣ | 集成第三方身份源 | LDAP / AD / 钉钉 / 飞书 |
| 4️⃣ | 多租户支持 | 每个企业租户独立登录域 |
| 5️⃣ | 风控与零信任 | 动态验证、MFA、地理限制 |
| 6️⃣ | 与 Passport 打通 | 登录后自动同步角色与权限 |
✅ 十二、总结一句话
SSO = 企业的统一登录大脑 它连接了用户（UMS）和权限（Passport）， 是企业身份体系从“分散登录”走向“统一安全”的中枢。
如果你想继续深入，我可以帮你：
- 📘 绘制一张 完整的 SSO 流程图（OAuth2 / OIDC 版本）
- 📦 生成一个 基于 Spring Authorization Server 的 SSO 示例工程
- 🧩 或者设计 与 UMS/Passport 打通的统一认证架构图
你希望我接下来帮你展开哪一部分？（流程图 / 示例工程 / 架构整合）
