KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

04 · 什么时候别用它 — keel 龙骨

前三章你已经会"跑起来"和"接进去"了。这一章收口到一件更重要的事： 什么时候不该用 SSO。

前三章你已经会"跑起来"和"接进去"了。这一章收口到一件更重要的事：
什么时候不该用 SSO。

先把手上的实验环境清掉——顺便这就是这一章要你敲的那条命令：

docker rm -f sso-kc

输出就是容器名，一行：

sso-kc

再确认它真的没了：

docker ps --filter name=sso-kc

预期：只剩表头一行，没有数据行。这就是"清干净了"的形状。

一、五类"别用它"的场景

一个技术用得对不对，往往不取决于你多会用它，而取决于你知不知道它的边界。

1. 你只有一个系统

SSO 消掉的是"同一个身份要在多个系统间对齐"这件事。如果你从头到尾只有一个系统，
它自己那张账号表就是唯一权威，压根没有"对齐"的问题——引入 SSO 只是给它加了一道
本不必要的跳转。

判断句：有几个系统要共享同一套登录？ 答案 ≤ 1，SSO 能给的收益接近零。

2. 纯内部工具，不值得维护一个 IdP

一个只有三五个同事用的后台，为了它专门维护一个 IdP——
你就多了一个要一直跑着的服务、一套要备份的用户数据、一个会挂的环节。
这种情况下，用最土的用户名密码，或者在反向代理那一层放个统一的 basic auth，已经够了。

3. 公司已经有企业 IdP 了

如果公司已经在用某个统一登录（AD、钉钉/飞书、Entra 之类），
正确动作是"把你的应用接进去"，而不是在旁边再自己搭一个。
自建第二个的唯一结果是：又多了一套要同步的账号，多了一处会不一致的地方。

4. 不能接受外部依赖的关键系统

有些系统的可用性要求是"就算外部全挂，我也得能进"——比如机房的本地应急入口、
离线设备的管理台。把登录押在一个外部 IdP 上，等于把这个系统的可用性也绑了过去。
这类系统要能留一条本地入口，SSO 只作为常规路径。

5. 把 SSO 当成权限系统用

这是最隐蔽的一类："我们上了 SSO，权限就统一管住了吧？"——并没有。
SSO 只给出"你是谁"，谁登录进来看到哪几张表、能不能导出，是另一件事。
指望 SSO 顺手解决权限，最后会发现权限还散在各应用里，只是登录变统一了。

一条把它们串起来的线索

上面五条其实是同一句话的不同侧面：

SSO 的价值，来自两件事同时成立：① 有多个系统要共享同一个"你是谁"；
② 你愿意、也承担得起，把"证明身份"这件事交给一个外部角色。

两个都成立才值；缺任何一个，收益就掉到负数——因为你换来的是额外的维护、额外的依赖。
所以拿到需求先问的不是"怎么接 SSO"，而是这两句："有几个系统？" 和 "这件事我能交给谁？"

二、一张速查表（判断时回来查）

三、它不是什么

• "能跑起来"不等于"该自己跑"。 本课让你用 start-dev 顺手跑起了一个 IdP，
  但自己搭一个 IdP 不是接入 SSO 的默认解法——有现成的（企业已有的、或托管的）优先接。
• 删掉容器也不等于"注销了会话"。 刚才那条 docker rm -f sso-kc 是把整套配置一起抹掉；
  而真实的"单点登出"是另一回事（登出一次、多个应用一起失效），
  它属于《SSO 应用课》的范围。

读完你能做什么

走到这里，这门课的目标就完成了：

• 能说清 SSO 解决的是"同一个身份在多系统间对齐"，并说出它不管什么；
• 能跑起一个 IdP、把一个应用接进去、看清回跳地址里的每个参数；
• 能判断一件事该不该上 SSO——这是这一章最想留给你的东西。

下一步去哪

• 想知道"用对"是什么样：《SSO 应用课》。
  它不讲"怎么跑起来"（你已经会了），讲的是协议里的坑、令牌怎么验、
  单点登出怎么做、出事怎么查——那门课也是这门课的自然下一步。
• 遇到某个名词卡住：《SSO 概念课》。
  realm、断言、令牌这样的词，各自一页讲它的来历和形态，卡住时点进去。
• 想弄清"授权"那件事（SSO 明确不管的那半边）：
  《权限与多租户》。
  它回答的是"登录之后，你能做什么"。

这门课到这里就结束了。它刻意不长——你已经知道它是什么、边界在哪，
剩下的交给需要的时候再学。

进入 keel 阅读