当前位置：首页 > news >正文

SSO 单点登录超深度架构

news 2026/4/29 22:00:26

SSO 单点登录超深度架构版本（2023-10-01）

SSO 单点登录架构超深度完整版（原理 + 角色 + 每步时序 + 底层机制 + 优劣 + 落地细节）

前置核心定义与必懂基础

1. SSO 本质定义

单点登录 SSO：在多个独立、域名可不同、部署隔离的业务系统集群中，用户仅做一次账号密码认证，后续访问所有信任业务系统，无需重复登录；同时支持单点注销 SLO：任意一处登出，全集群全部下线。

2. 标准三方核心角色（所有 SSO 通用）

User 用户：浏览器 / APP / 客户端
IdP 身份提供者（认证中心） 唯一登录入口、账号密码校验、全局会话维护、签发身份票据 / 令牌、管理单点登出、统一用户中心。整个系统只存在一个 IdP。
SP 服务提供者（业务系统） OA、CRM、ERP、工单、财务、各微服务前台，只负责资源鉴权，不做账号密码登录校验，全部委托 IdP。

3. 关键基础概念拆解

全局会话：IdP 端保存的用户登录状态，登录后生成，是 SSO 免登的核心依据。
局部会话：每个 SP 业务系统本地的 Session/Cookie 会话，只作用于当前系统。
票据 Ticket：一次性、短时效、不可伪造的临时身份凭证，CAS 核心载体。
跨域：一级域名不同（a.com、b.com），浏览器同源策略禁止互相读写 Cookie，是 SSO 要解决的最大难点。
单点登出 SLO：销毁 IdP 全局会话 + 销毁所有 SP 局部会话。

一、方案一：同主域子域 SSO（共享 Cookie 架构）

1. 适用边界

所有业务系统同一级主域名：

主域：company.com
IdP：sso.company.com
SP1：oa.company.com
SP2：crm.company.com
SP3：erp.company.com

原理底层：浏览器允许主域种下的 Cookie，所有子域名自动携带、可访问。

2. 完整详细时序流程（逐步拆解）

用户首次访问 SP oa.company.com
1. SP 拦截请求，检查本地 Session/Cookie，无登录态。
2. 302 重定向到 IdP：sso.company.com/login?redirect=当前回跳地址。
IdP 检测全局会话
1. IdP 发现无全局登录态，返回统一登录页面。
2. 用户输入账号 + 密码 + 验证码，提交给 IdP 后端。
IdP 认证通过，创建全局会话 + 种下主域 Cookie
1. 后端校验账号密码合法，生成全局 Session存入 Redis / 服务端内存。
2. 设置 Cookie：
  - Domain = .company.com（关键点：带点代表主域所有子域共享）
  - HttpOnly、Secure、SameSite 开启
  - Value = 全局 SessionId
IdP 重定向回业务系统 SP 302 跳转到传入的redirect地址，携带会话标识。
SP 接收请求，读取主域 Cookie
1. 浏览器自动带上 .company.com 下的共享 Cookie。
2. SP 后端根据 SessionId 去 IdP 校验 / 本地共享会话存储校验。
3. 校验通过，创建 SP 本地局部 Session，写入自身业务 Cookie。
4. 用户进入业务系统，登录成功。
访问第二个子系统 crm.company.com
1. 访问 crm，无本地会话，重定向 IdP。
2. 浏览器自动携带主域共享 Cookie到 IdP。
3. IdP 识别已有全局会话，无需再输密码。
4. 直接重定向回 crm，crm 建立局部会话，免登完成。
登出流程
1. 在任意 SP 点击退出，请求打到 IdP 登出接口。
2. IdP 销毁全局 Session、清空主域共享 Cookie。
3. 跳转各 SP，清除各自本地局部 Cookie/Session，实现单点登出。

3. 底层限制与技术细节

依赖浏览器 Cookie 同源策略特性，只能同主域，无法跨一级域名。
所有子系统必须信任同一主域，无法对接外部第三方系统。
会话集中在主域，只要主域 Cookie 有效，所有子域都免登。

4. 优缺点

✅ 实现最简单、无额外协议、无远程票据校验、性能最高、运维简单 ❌ 仅支持同主域、跨一级域名彻底失效、存在 CSRF/XSS 攻击风险、不适合异构外部系统

二、方案二：CAS 协议 SSO（企业级跨域标准架构，最核心）

1. 架构版本

CAS 分为 V1、V2、V3，企业常用CAS V2 协议，支持跨域、票据校验、单点登出。

2. 核心核心构件

IdP：CAS 认证中心
SP：各个跨域业务系统
ST：Service Ticket 服务票据一次性
TGT：Ticket Granting Ticket 全局登录票据（IdP 全局会话）
PGTT：全局会话凭证，保存在 IdP Cookie 中

3. 完整超详细时序流程（一步不漏）

阶段 1：首次访问业务系统 SP，未登录

用户访问 https://sp-a.com 业务资源。
SP 拦截器检测无本地局部会话。
SP 构造重定向地址，302 跳转到 CAS IdP：
```
https://sso.cas.com/login?service=https://sp-a.com/callback
```
service 是登录成功后 IdP 要回跳的 SP 回调地址。

阶段 2：IdP 登录认证，生成全局会话 TGT

IdP 接收请求，检测请求中无全局 PGTT Cookie，判定未登录。
返回 CAS 统一登录页面，用户输入账号密码验证码提交。
IdP 后端校验账号密码合法：
1. 生成 TGT 全局会话票据 存入 Redis / 数据库。
2. 向浏览器种下 PGTT Cookie（IdP 独立域名下，做全局登录标识）。

阶段 3：IdP 生成一次性 ST 票据，回跳 SP

IdP 生成 一次性 ST 服务票据（随机串、5 分钟过期、只能校验一次）。
302 重定向回 SP 传入的service地址，URL 携带：?ticket=ST-xxxxxx。

阶段 4：SP 后端服务端内网校验 ST 票据（关键安全点）

SP 后端拿到 URL 中的 ticket，前端不做校验，后端发起 HTTP 调用：

https://sso.cas.com/p3/serviceValidate?ticket=STxxx&service=https://sp-a.com/callback

IdP 接收校验请求：
1. 校验 ST 票据是否存在、是否过期、是否已被使用、是否匹配当前 SP 服务地址。
2. 校验通过，返回明文 / XML 用户唯一标识（用户名 / 工号）。
3. 立即作废当前 ST 票据，保证一次性不可重放。

阶段 5：SP 建立本地局部会话，完成登录

SP 拿到用户身份，创建本地 Session，种下自身业务 Cookie。
后续用户访问该 SP 任意接口，携带本地 Cookie，直接免登。

阶段 6：访问第二个跨域业务系统 sp-b.com

访问sp-b.com，无本地会话，重定向 IdP。
浏览器请求 IdP 时，自动带上 PGTT 全局 Cookie。
IdP 检测已有合法 TGT 全局会话，不展示登录页。
直接生成新的一次性 ST 票据，重定向回 sp-b 回调地址。
sp-b 后端同样远程校验 ST，通过后建立局部会话，全程免输密码。

4. CAS 单点登出 SLO 完整流程

用户在任意 SP 点击【退出登录】。
请求发到 IdP 登出接口。
IdP 销毁TGT 全局会话、清空 PGTT Cookie。
IdP遍历所有已登录的 SP 系统，逐个主动回调各 SP 的登出回调地址。
每个 SP 收到登出请求，主动销毁本地局部 Session/Cookie。
此时所有业务系统全部下线，实现一处登出，全集群下线。

5. CAS 核心技术特性

ST 票据一次性、短时效，防抓包重放攻击。
票据校验后端内网调用，前端无法篡改、无法绕过。
完全支持跨不同一级域名，企业内网异构系统首选。
协议标准化，开源框架支持：Apereo CAS、Shiro CAS、SpringSecurity CAS。

6. 优缺点

✅ 跨域完美支持、安全等级高、标准协议、单点登出完善、企业落地最多 ❌ 跳转链路多、依赖独立 CAS 中心、每次新 SP 都要一次跳转 + 后端校验

三、方案三：OAuth2.0 + OIDC 实现 SSO（互联网第三方登录）

1. 基础区分

OAuth2.0：只是授权协议，不负责身份认证，只能拿资源权限。
OIDC OpenID Connect：基于 OAuth2.0 扩展，增加身份认证层，专门用来做 SSO。
核心载体：ID Token（JWT 格式） 承载用户身份。

2. 四大角色

资源所有者：用户
客户端 Client：业务系统 SP
授权服务器：IdP（微信、钉钉、企业微信、自研认证中心）
资源服务器：存放用户信息接口

3. 授权码模式（最安全、生产唯一用）完整详细流程

用户访问业务系统 SP，无登录态。
SP 拼接参数重定向到 OIDC 授权中心：携带：client_id、redirect_uri、response_type=code、scope=openid、state 随机串。
授权中心检测登录态：
1. 未登录：展示登录页，输入账号密码。
2. 已登录：直接跳过登录。
用户确认授权，授权中心生成一次性 Authorization Code 授权码。
302 重定向回 SP 回调地址，URL 携带 code=xxx&state=xxx。
SP 后端发起请求，用 code + client_id + client_secret 向授权中心换取令牌。
授权中心校验合法，返回三样东西：
1. Access Token：访问资源接口凭证
2. ID Token：JWT 身份令牌，核心 SSO 依据
3. Refresh Token：刷新令牌
SP解析 ID Token（验签、过期、iss、aud 校验），拿到用户工号、账号、昵称。
SP 建立本地会话，完成登录。
同授权中心下其他应用，一次登录全部免登。

4. 适用场景与局限

适用于：微信 / QQ / 支付宝登录、钉钉企业 SSO、对外第三方应用接入。
不适合：传统企业内网强管控单点登出场景。

四、方案四：JWT 无状态 SSO（微服务 / 前后端分离 / APP）

1. 核心原理

放弃服务端全局 Session，所有系统共用同一套签名秘钥 / 非对称公私钥。登录中心签发 JWT，各业务系统本地自行验签解析，无需远程调用 IdP。

2. 完整详细流程

用户在 SSO 登录中心输入账号密码。
IdP 认证通过，用私钥 RSA / 秘钥 HS256 生成 JWT。 JWT 载荷包含：用户 ID、账号、角色、过期时间、签发方、接收方。
前端把 JWT 存入 LocalStorage / 内存（不建议存 Cookie 防 XSS）。
前端每次请求业务接口，请求头携带： Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
所有微服务 / 业务系统本地用公钥 / 秘钥验签：
1. 校验签名合法性
2. 校验是否过期
3. 校验签发受众是否匹配
校验通过，直接从 JWT 载荷取出用户身份，完成登录鉴权。
所有系统只要能解析 JWT，一次登录，全系统免登，无跨域限制。

3. 关键痛点：单点登出难点

JWT 无状态，签发后服务端无法主动作废，只能妥协方案：

引入 Redis JWT 黑名单，登出时把令牌加入黑名单，每次鉴权先查黑名单。
缩短 JWT 过期时间，配合 Refresh Token 无感刷新。

4. 优缺点

✅ 完全无状态、不依赖中心存储、微服务天生适配、跨域最简单、适合 APP / 小程序 ❌ 原生不支持优雅单点登出、JWT 一旦泄露有效期内可冒用、载荷不能存敏感信息

五、四种 SSO 架构全维度深度对比

方案	跨一级域名	有状态 / 无状态	单点登出能力	跳转次数	适用场景	安全级别
子域共享 Cookie	不支持	有状态	简易支持	少	同公司子系统	中
CAS 票据模式	完全支持	有状态	完美强支持	多	企业内网异构系统	高
OIDC OAuth2.0	完全支持	半有状态	标准支持	多	互联网第三方登录	高
JWT 无状态	完全支持	无状态	需黑名单妥协	最少	微服务、APP、前后端分离	中高