KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
SSO 工程课：协议、令牌与会话 — keel 龙骨
这门课不站在「怎么把 SSO 接进来」的起点上，而是站在接进来之后它不按预期工作的起点上。
这门课不站在「怎么把 SSO 接进来」的起点上，而是站在接进来之后它不按预期工作的起点上。
章节目录
- 01 · 全景与选型：三条协议各在哪一层 — 这一章先不教你配任何东西。它要解决的是另一件事：把「登录」这个词拆成三个可以分开判断的问题—— 谁在证明你是谁、用什么把它证明出去、以及这些结论在哪一层生效。 拆不开这三个问题，选型就只能是「同事说用 OIDC 那就用 OIDC」。
- 02 · 授权码流与 PKCE：把一次登录逐步拆开 — 这一章兑现第 01 章的那一眼：那两段 URL 里的每个参数，是谁在什么时候放进来的。 顺序不是任选的——每一步都在为下一步制造一个只能用一次的东西。 把这些「一次性」搞错一处，就会得到本章最后那三条失败路径中的一条。
- 03 · 令牌与校验：三种东西，六项检查 — 02 章末尾换回来三样东西：accesstoken、idtoken、refresh_token。 它们都长得像 JWT、都是三段式、都能被解出 JSON——但它们不是一个东西。 把它们当成同一个东西，会直接产生两类线上问题：拿身份结论去调接口， 或者把一把能调接口的钥匙放进浏览器。
- 04 · 会话与登出：单点登录靠什么成立 — 「登录过」这三个字，在 SSO 里不是一个状态，而是三处状态的组合： 浏览器上的 cookie、IdP 侧的会话、应用自己的会话。 单点登录能成立，是因为第二处还在；登出之所以难，是因为三处都要清—— 而第三处不归 IdP 管。
- 05 · 联邦与多租户：一个应用，几家 IdP — 前四章都只有一个 IdP。真实场景里有两个方向会把这个前提打破： 你的系统卖给多家客户（每家带自己的 IdP），或者你自己在多个系统之间流转（同一套代码接多家）。 这一章讲打破之后新增的那几件事：怎么区分来源、sub 还能不能用、账号怎么关联。
- 06 · 故障注入与排障：五类断点，一张表 — 前面五章建立的每一条结论，都可以反着用一次：把它破坏掉，看现象。 这一章不给新概念，只做两件事：把五类故障做成「症状 → 去哪看 → 根因」的表， 再给一个固定的查看顺序——让排障从「逐个配置项比对」变成「按顺序排除」。
- 07 · 生产边界：从单实例到真实部署 — 前六章的所有结论都有一个共同的前提：一个进程、一份内存、一把密钥、一段 http。 这一章逐条把这个前提拆掉。每一节都长成同一个形状： 教学替身是什么 → 真实替换点是什么 → 不换会出什么事。