SSO 全称 Single Sign-On，中文叫单点登录。一句话解释：登录一次，全部系统通行。
一、用生活场景理解
你去一个大型商场，进门保安核验了你的身份证，给你发了一个手环。之后你去里面的每一家店，店员看到手环直接放行，不会再让你掏身份证。
SSO 就是这个手环机制——登录一次换到一个凭证，公司所有系统认这个凭证就够了。
二、没有 SSO 之前是什么样子
假设公司有三个系统：OA 系统、CRM 系统、财务系统。
用户打开 OA → 输入账号密码登录
用户打开 CRM → 再输一次账号密码
用户打开财务 → 再输一次账号密码
换个浏览器 → 三个全重来
Token 过期了 → 三个全重来每个系统各自维护一套用户表、一套登录逻辑、一套 Token，互相不认识。用户体验差，运维成本高，安全管控也分散。
三、有了 SSO 之后
用户打开 OA → 跳到认证中心登录一次
用户打开 CRM → 认证中心发现已登录，直接放行，不需要再输密码
用户打开财务 → 同上，直接放行
任意系统登出 → 认证中心通知所有系统同步登出四、SSO 核心流程
┌──────────────┐ ┌──────────────────┐ ┌─────────────┐
│ 用户浏览器 │ │ 认证中心 (IdP) │ │ 业务系统 A │
└──────┬───────┘ └────────┬─────────┘ └──────┬──────┘
│ │ │
│ 1. 访问业务系统 A │
│ ──────────────────────────────────────────────── > │
│ │ │
│ │ 2. 未登录，重定向认证中心 │
│ < ──────────────────────────────────────────────── │
│ │ │
│ 3. 跳转认证中心，带上 redirect 参数 │
│ ──────────────────── > │ │
│ │ │
│ 4. 输入账号密码 │ │
│ ──────────────────── > │ │
│ │ │
│ 5. 验证成功，下发 Token + 种 SSO Cookie │
│ < ──────────────────────│ │
│ │ │
│ 6. 携带 Token 跳回业务系统 A │
│ ──────────────────────────────────────────────── > │
│ │ │
│ │ 7. 业务系统验证 Token │
│ │ < ────────────────────── │
│ │ │
│ │ 8. 验证通过，返回用户信息 │
│ │ ────────────────────── > │
│ │ │
│ 9. 登录成功，进入系统 │ │
│ < ─────────────────────────────────────────────── │
│ │ │
│ 10. 再访问业务系统 B │ │
│ ──────────────────── > │ │
│ │ │
│ 11. 检测到 SSO Cookie，直接下发 Token，跳过第 4 步 │
│ < ──────────────────────│ │关键点：第 10 步访问系统 B 时，认证中心检测到浏览器里的 SSO Cookie，确认已登录，直接颁发新 Token 给系统 B，用户全程没有输密码。
五、为什么需要 SSO —— 五个真实痛点
痛点 1：用户体验差
公司员工每天用 5 个内部系统，没有 SSO 每个都要登录一次。Token 过期时间设短了频繁掉线，设长了安全风险大，左右为难。
痛点 2：账号管理混乱
每个系统各自维护用户表，员工入职要在 5 个系统分别创建账号，离职要在 5 个系统分别禁用。忘了禁某一个，离职员工还能访问内部数据——这是真实发生过的安全事故。
痛点 3：安全策略不统一
密码强度要求、登录失败锁定、双因素验证，各系统各搞各的，安全水平参差不齐。SSO 把认证收归一处，统一加固一个地方就够了。
痛点 4：代码重复维护
每个前端项目都写一套登录页、Token 存储、刷新逻辑、路由守卫，同一个 bug 要修 N 个地方。
痛点 5：审计困难
用户的登录行为分散在各系统日志里，要查一个人今天访问了哪些系统，得去 5 个地方分别捞日志。SSO 把认证收归一处，一份日志全覆盖。
六、常见 SSO 协议对比
| 协议 | 全称 | 适用场景 | 特点 |
|---|---|---|---|
| OAuth 2.0 | Open Authorization | 第三方授权（微信登录、GitHub 登录） | 授权框架，不是认证协议本身 |
| OIDC | OpenID Connect | 企业 SSO 主流方案 | OAuth 2.0 上加了身份认证层，基于 JWT |
| SAML 2.0 | Security Assertion Markup Language | 老企业、政府系统 | XML 格式，重但成熟稳定 |
| CAS | Central Authentication Service | 高校系统最常见 | 简单轻量，适合内网场景 |
公司自研系统做 SSO，通常选 OIDC（JWT 友好，前端容易处理）或者自己实现一套简化版 Token 认证中心。
七、单点登出（Single Logout）
登录容易被忽视的是登出。SSO 里的登出分两种：
局部登出：只退出当前系统，其他系统仍保持登录。适合临时借用他人电脑的场景。
全局登出（Single Logout）：退出认证中心，所有系统同步登出。适合安全要求高的场景。
用户在系统 A 点退出
→ 系统 A 清掉本地 Token
→ 通知认证中心销毁 SSO Session
→ 认证中心广播通知系统 B、系统 C
→ 系统 B、C 各自清掉本地 Session / Token
→ 用户所有系统全部下线前端实现全局登出同步，通常用 BroadcastChannel 在同源多 Tab 之间广播登出消息，配合后端的 Session 失效通知。
八、前端在 SSO 里具体负责什么
认证中心是后端搭的，前端主要负责这几件事：
1. 路由守卫 → 未登录时拦截，重定向到认证中心登录页
2. Token 接收 → 认证中心回跳时，从 URL 参数里取 Token 存好
3. 请求拦截器 → 每个接口请求自动在 header 带上 Token
4. 无感刷新 → Token 过期时自动用 Refresh Token 换新的，用户无感知
5. 多 Tab 同步 → 一个 Tab 登出，其他 Tab 同步跳到登录页
6. SDK 封装 → 把上面五件事打成 SDK 包，其他项目 install 即用九、Token 无感刷新流程（前端核心难点）
正常请求
前端 ──── 携带 Access Token ────> 后端
前端 <─── 200 正常响应 ───────── 后端
Token 过期场景
前端 ──── 携带过期 Token ────────> 后端
前端 <─── 401 Unauthorized ────── 后端
前端（内部处理，用户无感知）
│
├── 检测到 401，加刷新锁（防并发）
│
├── 携带 Refresh Token 请求 /auth/refresh
│ └── 后端返回新的 Access Token + Refresh Token
│
├── 更新内存里的 Access Token
│
├── 用新 Token 重放刚才失败的请求
│
└── 返回正常响应给业务代码（业务代码完全不知道发生了什么）
并发场景（同时有 5 个请求，全部 401）
第 1 个 401 → 抢到锁，开始刷新
第 2~5 个 401 → 检测到锁，进入等待队列
刷新成功 → 广播新 Token，队列里 4 个请求拿到 Token 重新发
刷新失败 → 清 Token，全部请求报错，跳登录页十、一句话总结
SSO 解决的核心问题是：把分散在各系统里的认证逻辑收归一处统一管理。
对用户来说是体验提升，对公司来说是安全收口，对开发来说是减少重复代码。前端侧的难点集中在 Token 的安全存储、无感刷新的并发处理、多 Tab 状态同步这三块，也是面试里最常被追问的地方。