为什么感觉类似？
你这个“感觉”其实非常准，而且问到了一个很多架构设计都会踩坑的核心分裂点。
我直接先给结论：
你之所以觉得这些是 SSO 的事，是因为： 在很多公司里，Passport 和 SOO 实际上被混在了一起。
但从架构上看，它们的关注点是不同的，只是高度重叠。
一句话帮你拆开它们
用最直白的方式区分：
✅ Passport 关注的是：
“我是谁，你信不信？”
- 身份认证
- 凭证颁发
- Token / Session 管理
- 登录安全
- 验证机制
它是： 👉 身份认证中心（Identity Provider）
✅ SSO 平台关注的是：
“一次登录，哪些系统能用这个身份？”
- 登录态共享
- 跨系统访问
- 系统接入规范
- 跳转策略
- 登录链路编排
它是： 👉 登录态分发与协调平台
为什么你会觉得它们是一个东西？
因为在实际产品中，通常长这样：
Passport 系统 = 登录 + Token + Session + SSO
所以你看到的“Passport”做了很多“SSO的事”。
但从职责上更清晰的划分应该是：
SSO = 流程协调
Passport = 能力提供
用你熟悉的微服务思维打个比方
| 角色 | 类比 |
|---|---|
| Passport | 鉴权服务 auth-service |
| SSO平台 | 网关或登录编排层 |
SSO 更多是 orchestration（编排），Passport 是 capability（能力）。
功能对比更清晰看
| 维度 | Passport | SSO平台 |
|---|---|---|
| 用户是谁 | ✅ 核心 | ❌ 调用 |
| 登录校验 | ✅ 核心 | ❌ 依赖 |
| token生成 | ✅ 核心 | ❌ 透传 |
| 登录转发 | ❌ 可选 | ✅ 核心 |
| 登录跳转 | ❌ 可选 | ✅ 核心 |
| 系统接入管理 | ⚠️ 辅助 | ✅ 核心 |
| 登录态共享 | ⚠️ 辅助 | ✅ 核心 |
| 登录流程设计 | ❌ | ✅ |
所以你直觉上没错： 很多你看到的能力，确实更像 SSO 平台的职责。
正确的架构关系图应该是这样
理想解耦模型：
┌────────────┐
系统A → │ SSO平台 │
│ 登录编排 │
系统B → │ 路由跳转 │
└────┬─────┘
↓
┌────────────┐
│ Passport │
│ 身份认证中心│
└────────────┘
↓
┌────────────┐
│ UMS │
│ 用户数据 │
└────────────┘
职责路径：
-
SSO 决定： 去哪登录？登录完去哪里？
-
Passport 决定： 你是不是合法用户？
那很多公司为什么直接“Passport=SSO”？
因为现实考虑：
- 系统规模不大
- 拆太细维护成本高
- 团队人力有限
- 协议标准不复杂
于是演化为：
Passport平台 = 登录 + 跳转 + token + session + SSO
这并不是错，只是“职责耦合”。
从架构成熟角度来看会经历三个阶段
阶段1：一体化 Passport（最常见）
Passport = 登录 + 认证 + SSO + redirect
阶段2：逻辑分层
SSO层：流程控制
Passport：身份认证
阶段3：企业级身份平台
IAM平台 = Passport + SSO + 权限 + 风控 + 审计
那你的直觉应该怎么用？
你的直觉说明你在往平台架构的正确方向靠：
不是“Passport 是否管 SSO”， 而是“是否应该把流程职责从 Passport 抽离出来”。
这就是成熟架构的思考方式。
给你一版更工程化的划分建议
如果你要做得清晰：
Passport 只关心：
- authenticate(username, password)
- validateToken(token)
- issueToken()
- refreshToken()
SSO 平台负责：
- /login 路由
- redirect 管理
- client 系统注册
- 登录入口选择策略
一句话总结：
你说得对，但更准确的说法是：
SSO 是流程平台 Passport 是身份能力核心 现实中经常合体出现
也可以这样理解：
- Passport = 发身份证
- SSO = 检票系统+通行路线
如果你正在设计体系，这里有个判断建议
问自己三个问题：
- 是否需要多个登录入口策略？
- 是否需要第三方系统复杂接入？
- 是否有计划对外开放？
如果三个都否： 👉 Passport + 内部SSO一体即可
如果有一个以上是是： 👉 建议分层设计
