这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
单点登出
登出比登录难
SSO 里最容易翻车的不是登录，而是登出。
用户在认证中心退出后，问题来了：各业务系统的本地会话要不要一起失效？
如果只清掉 IdP 的全局会话，业务系统的本地会话可能仍然有效——用户以为「已退出」，但攻击者若拿到某个系统的本地会话，仍然能持续访问。这就是会话残留。
三种登出策略
| 策略 | 做法 | 可靠性 | 成本 |
|---|---|---|---|
| 前端重定向通知 | 前端逐个跳转到各业务系统通知登出 | 依赖浏览器跳转，可能漏 | 低 |
| 后端通道通知 | IdP 通过服务端回调通知各业务系统撤销会话 | 可靠 | 高，需维护回调 |
| 缩短本地会话 | 业务系统本地会话很短，降低残留风险 | 中 | 低，但体验略差 |
如何选
选择不是「越彻底越好」，而是看安全要求：
- 内部管理系统（后台、财务、客服）：要求统一登出，用后端通道通知为主，务必彻底。
- 普通内容站点：可以放宽，本地会话短一点即可。
统一登出越彻底，实现越复杂。关键是先想清楚：哪些系统残留会话会造成实际损失。
后端通道通知的实现要点
如果走后端通道（如 OpenID Connect 的 back-channel logout / SAML 的 Single Logout），注意：
- 各业务系统提供登出回调地址，IdP 在用户登出时服务端调用。
- 回调要鉴权（防止伪造登出请求）。
- 业务系统收到通知后，撤销指定会话（按
session_id或sub）。 - 全程记录审计日志：谁在何时发起登出、通知了哪些系统、结果如何。
登出体验
- 用户主动登出时，跳回一个「已退出所有系统」的确认页。
- 被动失效（会话过期）时，提示重新登录即可，不必大张旗鼓。
下一节看 SSO 的信任边界——为什么 IdP 一旦被攻破，等于所有系统的钥匙都丢了。
发现内容有问题？
告诉我们哪里需要改进。