单点登录（SSO）

单点登录（Single Sign-On，简称 SSO）是身份认证领域的核心解决方案，旨在解决 “多系统重复登录” 的痛点（用户只需在统一认证中心完成一次身份验证，即可免登录访问所有相互信任的关联系统。）。

## 定义

SSO 并非单一技术，而是一种**基于 “信任联盟” 的身份认证架构方案**，其核心逻辑是：

- 建立一个 “统一认证中心（Identity Provider，简称 IdP）”，所有信任该中心的系统（Service Provider，简称 SP）不再单独维护用户账号和认证逻辑；
- 用户首次访问某 SP 时，需跳转至 IdP 完成身份验证；验证通过后，IdP 向 SP 发放 “身份凭证”，SP 基于该凭证确认用户身份，无需再次登录；
- 后续用户访问其他信任 IdP 的 SP 时，IdP 直接复用已有的 “全局会话”，无需用户重复输入凭证，实现 “一次登录，多系统通行”。

> 关键特征

**统一身份源**：所有 SP 共享 IdP 的用户身份数据（如账号、部门、角色），避免 “多系统账号不一致”（如 OA 用手机号、CRM 用工号）；

**跨系统会话共享**：IdP 维护 “全局会话”（用户登录状态），SP 维护 “局部会话”（用户在该系统的访问状态），全局会话有效时，SP 可直接创建局部会话；

**信任机制**：SP 与 IdP 之间通过预配置的 “信任关系”（如数字签名、密钥）确保身份凭证不被篡改或伪造；

**无感知体验**：用户仅需首次登录时输入凭证，后续访问其他 SP 时完全免交互，大幅提升操作效率。

> 差异

| 对比维度     | 普通登录（多系统独立认证）                 | SSO（统一认证）                       |
| ------------ | ------------------------------------------ | ------------------------------------- |
| 认证中心     | 每个系统自建认证模块（如 OA 有独立登录页） | 统一 IdP，所有 SP 依赖 IdP 认证       |
| 用户账号     | 多系统可能需单独注册（或账号不一致）       | 仅需 IdP 维护一套账号，多 SP 共享     |
| 登录体验     | 访问每个系统需重复输入账号密码             | 一次登录，免登录访问所有信任 SP       |
| 身份数据管理 | 多系统重复存储用户数据，易不一致           | 集中存储在 IdP，SP 按需获取，数据统一 |
| 安全管控     | 每个系统独立配置安全策略（如密码复杂度）   | 统一在 IdP 配置安全策略（如 MFA）     |

## 工作原理

SSO 的核心是 “**全局会话 + 身份凭证**” 的协同，其完整工作流程可分为 “首次登录某 SP” 和 “访问其他 SP 免登” 两个阶段，以下以 “企业员工访问 OA（SP1）和 CRM（SP2）” 为例解析：

> 第一阶段：用户首次访问SP1（OA系统）

**发起请求**：用户在浏览器输入 OA 地址，OA 检测到用户未创建 “局部会话”（无 OA 的登录 Cookie），判定用户未登录；

跳转至 IdP：OA 生成一个 “随机状态码（State）”（用于防 CSRF 攻击），将用户重定向至 IdP 的登录页，携带参数：

- `service`：目标 SP 的标识（如`https://oa.company.com`），告知 IdP “为哪个 SP 生成凭证”；
- `state`：OA 生成的随机码，后续需验证；

**用户身份验证**：IdP 检测到用户未创建 “全局会话”（无 IdP 的登录 Cookie），展示登录页，要求用户输入凭证（如账号密码 + MFA）；

**创建全局会话**：IdP 验证凭证有效后，在服务器端创建 “全局会话”（记录用户 ID、登录时间、过期时间），并向用户浏览器写入 IdP 的 “全局会话 Cookie”（用于标识全局会话）；

**生成身份凭证**：IdP 生成 “服务票据（Service Ticket，简称 ST）”—— 这是 SP 可验证的短期身份凭证（通常有效期 10 秒内，避免泄露后被滥用）；

重定向回 SP1：IdP 将用户重定向至 OA 的 “凭证验证接口”，携带参数：

- `ticket`：生成的 ST；
- `state`：OA 之前传递的随机码；

**SP1 验证凭证**：OA 收到 ST 后，通过 “后端接口” 向 IdP 发送验证请求（携带 ST 和 SP1 的标识）；IdP 验证 ST 有效（未过期、属于该 SP）后，返回用户的身份信息（如用户 ID=123，角色 = 销售）；

**创建局部会话**：OA 验证通过后，在服务器端创建 “局部会话”，并向用户浏览器写入 OA 的 “局部会话 Cookie”；同时，向用户返回 OA 的首页，首次登录完成。

> 第二阶段：用户访问SP2（CRM系统）

**发起请求**：用户在浏览器输入 CRM 地址，CRM 检测到无 “局部会话”，判定用户未登录；

**跳转至 IdP**：CRM 生成 state 参数，重定向至 IdP 的登录页，携带`service=https://crm.company.com`；

**IdP 检测全局会话**：IdP 读取用户浏览器的 “全局会话 Cookie”，查询到服务器端存在有效的全局会话，判定用户已登录，无需再次展示登录页；

**生成新的 ST**：IdP 为 CRM 生成新的 ST（与 OA 的 ST 不同，每个 SP 的 ST 独立）；

**重定向回 SP2**：IdP 将用户重定向至 CRM 的凭证验证接口，携带`ticket`和`state`；

**SP2 验证凭证与创建局部会话**：CRM 向 IdP 验证 ST 有效后，获取用户身份信息，创建 “局部会话”，返回 CRM 首页；

**免登完成**：用户无需输入任何凭证，直接进入 CRM 系统，实现跨系统免登。

> 相关概念

**全局会话（Global Session）**：由 IdP 维护的用户登录状态，存储在 IdP 服务器端（如 Redis），包含用户 ID、登录时间、过期时间（通常 2 小时），通过 IdP 的 Cookie 标识；

**局部会话（Local Session）**：由 SP 维护的用户在该系统的访问状态，存储在 SP 服务器端，仅在当前 SP 有效，通过 SP 的 Cookie 标识；

**服务票据（ST）**：IdP 发放给 SP 的短期身份凭证，仅用于单次验证（验证后立即失效），避免长期凭证泄露风险；

**信任关系**：SP 与 IdP 之间的 “约定”，通常通过以下方式确保安全：

- 预共享密钥：SP 和 IdP 使用相同的密钥对 ST 进行签名 / 验签；
- 数字证书：IdP 使用私钥签名身份信息，SP 使用 IdP 的公钥验签；
- 白名单：IdP 仅向已注册的 SP 发放 ST，防止非法 SP 获取凭证。

## 主流SSO协议对比

SSO 的落地依赖标准化协议（解决 “SP 与 IdP 如何通信”）和核心组件（解决 “功能落地”），不同协议适用于不同场景（如互联网、企业级、开源）。

SSO 协议的核心是定义 “SP 与 IdP 的通信格式” 和 “身份凭证的结构”，目前主流协议有 OIDC、SAML 2.0、CAS，三者的差异决定了适用场景。

| 协议类型                                       | 核心特点                                    | 数据格式        | 适用场景                                            | 典型案例                              |
| ---------------------------------------------- | ------------------------------------------- | --------------- | --------------------------------------------------- | ------------------------------------- |
| OIDC（OpenID Connect）                         | 基于 OAuth 2.0 扩展，轻量级，支持 JSON 格式 | JSON            | 互联网场景（APP、小程序、Web 服务）、移动终端       | 微信登录、谷歌登录、阿里云 SSO        |
| SAML 2.0（Security Assertion Markup Language） | 企业级标准，安全性高，支持复杂身份属性传递  | XML             | 企业内部系统（ERP、SAP）、跨组织认证（政府 / 金融） | 微软 AD FS、IBM SSO、企业 CRM/OA 集成 |
| CAS（Central Authentication Service）          | 开源框架，轻量级，专注 SSO 认证，无授权能力 | 自定义 XML/JSON | 小型企业、教育机构、开源系统                        | 高校图书馆系统、开源 ERP（如 Odoo）   |

## 核心技术组件

无论采用哪种协议，SSO 的落地都需要以下核心组件支撑：

> 身份提供商（Identity provider，IdP）

SSO 的核心，负责用户认证、全局会话管理、凭证发放，需具备：

- 用户管理模块：存储 / 查询用户账号、密码哈希、属性（如部门）；
- 认证模块：支持密码、MFA、生物识别等认证方式；
- 凭证生成模块：发放 ST、ID Token 等凭证；
- 信任管理模块：管理 SP 的注册信息（如 SP 标识、公钥）。

> 服务提供商（service provider，SP）

依赖 IdP 认证的业务系统，需具备：

- 跳转模块：检测到未登录时，重定向至 IdP；
- 凭证验证模块：向 IdP 验证 ST/ID Token 的有效性；
- 局部会话模块：维护用户在该 SP 的访问状态；

> 身份源（Identity source）

为 IdP 提供用户数据的系统，如：

- LDAP/AD 域：企业内部常用的身份存储（如微软 AD 域）；
- 数据库：小型系统常用的用户数据存储；
- 第三方身份源：如互联网场景的微信 / QQ 用户体系；

> 安全组件

确保 SSO 流程安全，包括：

- 加密模块：对传输的凭证（如 ST）进行加密；
- 签名模块：对身份信息（如 ID Token、SAML 断言）进行数字签名；
- 防攻击模块：防御 CSRF、XSS、重放攻击（如 state 参数、ST 短期有效）。

## 分类

根据 “部署模式” 和 “信任范围”，SSO 可分为不同类型，适用于不同场景。

> 按部署模式划分

**集中式SSO**

- 特点：仅部署一个 IdP，所有 SP 直接与该 IdP 建立信任关系；
- 优势：架构简单、维护成本低、身份数据完全统一；
- 劣势：IdP 单点故障会导致所有 SP 无法认证；
- 适用场景：中小型企业（内部系统数量≤50）、单一组织架构的机构（如学校、医院）。

**分布式SSO（联邦SSO）**

- 特点：部署多个 IdP，IdP 之间建立 “联邦信任”（如 A 公司的 IdP 信任 B 公司的 IdP），用户可通过任一 IdP 认证访问所有联邦内的 SP；
- 核心技术：SAML 2.0（支持跨 IdP 信任）、OIDC Federation；
- 优势：无单点故障、支持跨组织协作；
- 劣势：架构复杂、信任关系管理成本高；
- 适用场景：大型企业（多子公司、多地域）、跨组织协作（如供应链系统：供应商通过自身 IdP 访问核心企业的 SP）。

> 按信任范围划分

**内部SSO**

- 信任范围：仅企业 / 组织内部的 SP 信任 IdP；
- 典型场景：企业内部 OA、CRM、ERP、云存储系统的统一登录；
- 特点：用户身份数据存储在内部 IdP，不对外暴露。

**跨域SSO**

- 信任范围：不同域名的 SP 信任同一 IdP（如`oa.company.com`和`crm.company.com`属于不同子域名）；
- 核心挑战：浏览器的 “同源策略” 限制跨域 Cookie 访问，需通过 “后端接口验证凭证” 或 “共享域名 Cookie” 解决；
- 典型场景：同一品牌下的多 Web 服务（如阿里系的淘宝`taobao.com`和支付宝`alipay.com`）。

**跨组织SSO（联邦SSO）**

- 信任范围：不同组织的 SP 和 IdP 之间建立信任（如 A 公司的 SP 信任 B 公司的 IdP）；
- 典型场景：政府部门间系统（如税务局 IdP 认证后可访问工商局 SP）、供应链协作（供应商 IdP 认证后可访问核心企业的采购 SP）；
- 核心要求：需符合行业标准协议（如 SAML 2.0），确保跨组织身份安全传递。

## 主要风险挑战

**IdP 单点故障风险**

风险：若 IdP 宕机（如服务器故障、网络中断），所有依赖 IdP 的 SP 将无法完成认证，导致业务中断；

应对方案：

- 部署 IdP 集群（多节点负载均衡），确保高可用（可用性目标 99.99%）；
- 部分关键 SP 配置 “离线认证备份方案”（如本地缓存短期身份凭证）。

**安全依赖风险**

风险：IdP 成为 “单点攻击目标”—— 若 IdP 被攻破（如黑客获取用户凭证库），所有 SP 的安全防线将全面崩溃；

应对方案：

- 强化 IdP 安全：采用加密存储密码（如 bcrypt 哈希）、部署 WAF 防御 Web 攻击、定期安全渗透测试；
- 最小权限原则：IdP 向 SP 传递的身份信息仅包含 “必要字段”（如仅传用户 ID，不传手机号 / 邮箱）；
- 实时监控：监控 IdP 的异常操作（如批量获取凭证、高频验证请求），触发告警。

**跨域与兼容性问题**

风险：

- 浏览器同源策略限制跨域 Cookie 访问，可能导致全局会话无法识别；
- 老旧系统（如基于 COBOL 的遗留系统）难以集成 SSO 客户端；

应对方案：

- 跨域问题：使用 “后端验证凭证”（SP 通过 API 向 IdP 验证，不依赖 Cookie）或 “父域名共享 Cookie”；
- 兼容性问题：为老旧系统开发 “SSO 代理”（代理接收 IdP 凭证，转换为老旧系统的登录格式）。

**合规与隐私风险**

风险：若 IdP 存储用户敏感信息（如身份证号、银行卡号），跨组织传递时可能违反数据隐私法规（如 GDPR、《个人信息保护法》）；

应对方案：

- 数据脱敏：向 SP 传递身份信息时脱敏（如身份证号显示为 “110101********1234”）；
- 合规审计：确保 SSO 流程符合行业法规（如金融行业需满足 PCI DSS），保留完整的认证日志；
- 用户授权：跨组织传递身份信息前，需获取用户明确同意（如 “是否允许将您的姓名和部门信息共享给供应商系统”）。