这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。

SSO 核心角色与登录流程

为什么需要 SSO

当公司只有一个系统时，每个系统自己登录还能接受。但一旦有管理后台、数据平台、客服系统、开放平台和多个业务站点，问题就来了：

用户每进一个系统就要登录一次，体验极差。
每个系统各存一套账号，身份管理混乱。
某个系统被攻破，其它系统完全不知道。

SSO（Single Sign-On）要解决的正是：一次登录，多处访问。

三个核心角色

SSO 系统通常包含三个角色：

角色	作用
用户浏览器	保存全局登录态，访问多个业务系统
身份提供方 IdP	统一认证中心，负责登录、签发身份断言
业务系统 SP	依赖 IdP 判断用户身份，建立本地会话

业务系统不再各自处理密码，而是把用户重定向到 IdP 登录。登录成功后，IdP 把身份结果安全地传回业务系统。

一次完整的 SSO 登录

下面是一次「先访问 A、再访问 B」的完整流程：

SSO 单点登录流程

用户浏览器步骤 1

访问业务系统 A

用户第一次进入，A 检测到未登录

业务系统 SP步骤 2

A 重定向到认证中心 IdP

携带 client_id、redirect_uri 与 state

身份提供方 IdP步骤 3

用户在 IdP 完成登录

验证账号密码 / MFA，创建全局会话

身份提供方 IdP步骤 4

IdP 带授权码跳回 A

code 短期有效、一次性使用

业务系统 SP步骤 5

A 用 code 换取用户身份

校验签名与回调来源，建立 A 的本地会话

用户浏览器步骤 6

再访问业务系统 B

B 同样重定向到 IdP

身份提供方 IdP步骤 7

IdP 发现全局会话已存在

无需再次输入密码，直接完成登录

业务系统 SP步骤 8

B 建立自己的本地会话

用户在 A、B 均处于已登录状态

关键点： IdP 持有全局会话，各业务系统持有本地会话，两者的生命周期可能不同，登出策略要单独设计。

全局会话与本地会话

SSO 最关键的理解是：认证中心有全局会话，业务系统有本地会话，两者生命周期可能不同。

全局会话：在 IdP 侧，证明「用户已经在认证中心登录过」。
本地会话：在各业务系统侧，证明「用户在此系统已建立会话」。

用户访问第二个系统时，因为全局会话还在，不需要重新输入密码——这正是「单点登录」的体验来源。

从账号密码到 SSO 的演进

我自己的演进路径是这样的：

单系统：自己登录，自己管会话。
多系统：每个系统各自登录，身份数据分散、重复。
SSO：引入 IdP 统一认证，业务系统只做「本地会话 + 信任 IdP」。
再往后：接 OAuth 第三方、做 MFA 加固（后面章节展开）。

演进的核心驱动力，始终是「系统变多了，身份不能再各管各的」。

下一节看 SSO 里最容易被低估的一环：单点登出。