vault backup: 2026-07-13 11:11:37

technical/sso/sso-comparison.md

@@ -5,124 +5,145 @@ create time: 2026-07-13 10:03
 
 # SSO 协议对比与选型指南
 
-## 概述
+## TL;DR
 
-本文横向对比 CAS、SAML 2.0、OAuth 2.0、OIDC 四种主流 SSO 协议，帮助你在实际项目中做出合理的选型决策。
+> **不知道选什么？选 OIDC。** 它是当前最通用的 SSO 协议，支持 Web、移动端、SPA，生态最好，学习资源最丰富。
+>
+> 只有在以下情况才考虑其他协议：
+> - 客户要求 SAML 对接 → 用 **SAML 2.0**
+> - 只有内部 Web 系统、已有 CAS 基础设施 → 用 **CAS**
+> - 不需要认证，只需要 API 授权 → 用 **OAuth 2.0**
 
-## 横向对比总览
+## 四种协议一览
 
 | 维度 | CAS | SAML 2.0 | OAuth 2.0 | OIDC |
 |------|-----|----------|-----------|------|
-| **诞生年份** | 2000 | 2005 | 2012 | 2014 |
-| **数据格式** | 自定义 XML | XML | JSON | JSON (JWT) |
-| **传输层** | HTTP 重定向 | HTTP 重定向 + POST | HTTPS API | HTTPS API |
-| **核心目的** | 认证 (SSO) | 认证 (SSO) | 授权 | 认证 + 授权 |
-| **Token 类型** | Ticket (ST/TGT) | Assertion | access_token | id_token + access_token |
-| **移动端支持** | 差 | 差 | 好 | 优秀 |
-| **SPA 支持** | 差 | 差 | 好 (PKCE) | 优秀 (PKCE) |
-| **实现复杂度** | 低 | 高 | 中 | 中 |
-| **生态丰富度** | 一般 | 丰富 (企业级) | 极丰富 | 极丰富 |
-| **主要用户** | 高企内部系统 | 企业 B2B SaaS | 第三方登录 | 现代 Web/移动应用 |
+| **一句话定位** | 内网 Web SSO | 企业级联合认证 | API 授权框架 | 现代认证 + 授权 |
+| **诞生** | 2000（耶鲁大学） | 2005（OASIS 标准） | 2012（IETF RFC 6749） | 2014（OpenID Foundation） |
+| **数据格式** | 自定义 XML | 重量级 XML | JSON | JSON（JWT） |
+| **凭证类型** | Ticket（一次性票据） | Assertion（签名的 XML 文档） | access_token | id_token + access_token |
+| **移动端 / SPA** | ❌ 不适合 | ❌ 不适合 | ✅ 好（PKCE） | ✅ 最佳（PKCE） |
+| **实现复杂度** | ⭐ 低 | ⭐⭐⭐ 高 | ⭐⭐ 中 | ⭐⭐ 中 |
+| **Go 生态** | 一般 | 一般 | 优秀（标准库） | 优秀（go-oidc） |
+| **调试难度** | 低 | 高（XML 坑多） | 中 | 中 |
 
-## 各协议适用场景
+## 什么时候该选哪个？
 
-### 选择 CAS 的场景
+### OIDC — 默认选择
 
-- 企业内部多个传统 Web 系统需要统一登录
-- 已有 Apereo CAS Server 基础设施
-- 团队对 OAuth/JWT 不熟悉，需要快速落地
-- 不涉及移动端或第三方接入
+- ✅ 新项目、没有特殊约束
+- ✅ 需要支持移动端、SPA、微服务
+- ✅ 要对接 Keycloak、Auth0、Azure AD 等现代 IdP
+- ✅ 需要标准化的用户信息接口
 
-### 选择 SAML 2.0 的场景
+### SAML 2.0 — 企业客户要求时
 
-- 与企业客户的 IdP（AD FS、Okta）对接
-- 已有 AD/LDAP 用户体系，需要对外暴露 SSO
-- B2B SaaS 产品，客户要求 SAML 集成
-- 合规要求（如 FedRAMP、SOC 2）强制使用 SAML
+- ✅ 客户的 IT 部门只提供 SAML IdP（AD FS、Okta）
+- ✅ B2B SaaS 产品，客户要求 SAML 集成
+- ✅ 合规要求（FedRAMP、SOC 2）强制 SAML
+- ⚠️ 可以同时支持 OIDC + SAML（Keycloak 两者都支持）
 
-### 选择 OAuth 2.0 的场景
+### CAS — 遗留系统 / 简单场景
 
-- 第三方应用需要有限度地访问你的 API
-- 「用微信/GitHub 登录」这类需求
-- 纯 API 服务的访问控制（客户端凭证模式）
-- 服务间的 M2M 认证
+- ✅ 企业内网几个传统 Web 系统需要统一登录
+- ✅ 已有 Apereo CAS Server 基础设施
+- ✅ 团队不熟悉 OAuth/JWT，需要快速落地
+- ❌ 不适合移动端、SPA、第三方接入
 
-### 选择 OIDC 的场景
+### OAuth 2.0 — 只需要授权，不需要认证
 
-- **新项目的首选**——现代、通用、生态好
-- SPA / 移动端 / 微服务架构
-- 需要标准化的用户信息接口
-- 需要和主流 IdP（Keycloak、Auth0、Azure AD）对接
-
-## 技术栈对比
-
-### 数据格式
-
-| 格式 | 优点 | 缺点 |
-|------|------|------|
-| XML (SAML) | 严谨、标准完善 | 冗长、解析慢、安全风险多 |
-| JSON (OAuth/OIDC) | 轻量、开发者友好 | 规范相对灵活，需自行约束 |
-| JWT (OIDC ID Token) | 自包含、可离线验证 | 无法即时撤销、Payload 可见 |
-
-### 签名与加密
-
-| 协议 | 签名方式 | 加密支持 |
-|------|----------|----------|
-| CAS | 可选 (HMAC) | 不支持 |
-| SAML | XML Digital Signature（RSA/EC） | XML Encryption（RSA/AES） |
-| OAuth 2.0 | 无标准（靠 HTTPS） | 无标准 |
-| OIDC | JWT Signature（RS256/ES256） | JWE（可选） |
-
-> [!info] 为什么 OIDC 通常只签名不加密？
-> JWT 的 Payload 通常是用户 ID、邮箱等非敏感信息。签名保证完整性（不被篡改），HTTPS 保证传输安全。如果需要隐藏 Payload，使用 JWE 加密。
+- ✅ 第三方应用需要访问你的 API（如「用微信登录」）
+- ✅ 服务间调用（M2M），用客户端凭证模式
+- ⚠️ 如果需要知道「用户是谁」，请用 OIDC（OAuth 2.0 不提供用户身份信息）
 
 ## 选型决策树
 
 ```mermaid
 graph TD
-    A[需要 SSO] --> B{有移动端/SPA?}
-    B -->|是| C[OIDC]
-    B -->|否| D{对接企业客户 IdP?}
-    D -->|是| E{客户要求?}
+    A[需要 SSO] --> B{有移动端或 SPA？}
+    B -->|是| C[OIDC ✅]
+    B -->|否| D{需要对接企业客户 IdP？}
+    D -->|是| E{客户要求什么协议？}
     E -->|SAML| F[SAML 2.0]
-    E -->|OIDC| C
-    E -->|无要求| C
-    D -->|否| G{内部系统?}
-    G -->|是| H{已有基础设施?}
-    H -->|CAS Server| I[CAS]
-    H -->|Keycloak| C
-    H -->|无| C
-    G -->|否| J{第三方授权?}
+    E -->|OIDC 或无要求| C
+    D -->|否| G{只是内部 Web 系统？}
+    G -->|是| H{已有 CAS 基础设施？}
+    H -->|有| I[CAS]
+    H -->|没有| C
+    G -->|否| J{第三方 API 授权？}
     J -->|是| K[OAuth 2.0]
     J -->|否| C
 ```
 
-> [!tip] 默认选 OIDC
-> 如果你没有强烈的理由选择其他协议，**OIDC 是最安全的默认选择**。它覆盖了 SSO + 授权的完整场景，生态支持最好，学习资源最丰富。
+## 数据格式与签名
 
-## 接入成本评估
+| 格式 | 说明 | 优点 | 缺点 |
+|------|------|------|------|
+| **XML**（SAML/CAS） | 2000 年代企业标准 | 工具链成熟、标准严谨 | 冗长、解析慢、安全坑多（如 XML Signature Wrapping） |
+| **JSON**（OAuth 2.0） | 无 Token 结构约束 | 轻量、开发者友好 | 需要自行定义 Token 格式 |
+| **JWT**（OIDC） | JSON + 签名 | 自包含、可离线验证、标准统一 | Payload 可见（非加密）、无法即时撤销 |
+
+**签名能力对比：**
+
+| 协议 | 签名 | 加密 | 说明 |
+|------|------|------|------|
+| CAS | 可选（HMAC） | ❌ | 简单场景够用 |
+| SAML | ✅ XML Digital Signature | ✅ XML Encryption | 功能最全，但也最复杂 |
+| OAuth 2.0 | ❌ 无标准定义 | ❌ | 靠 HTTPS 保护传输安全 |
+| OIDC | ✅ JWT Signature（RS256/ES256） | 可选（JWE） | 签名是标配，加密是可选 |
+
+> [!info] 为什么 OIDC 通常只签名不加密？
+> JWT 的 Payload 通常是用户 ID、邮箱等非敏感信息。签名保证「内容没被篡改」，HTTPS 保证「传输过程不被窃听」。两者结合已经足够安全。如果你确实需要隐藏 Payload（比如把 JWT 放在 URL 里），可以用 JWE 加密。
+
+## 接入成本对比
 
 | 维度 | CAS | SAML | OAuth 2.0 | OIDC |
 |------|-----|------|-----------|------|
-| **Go 库成熟度** | 一般 | 一般 | 优秀 | 优秀 |
-| **调试难度** | 低 | 高（XML 解析坑多） | 中 | 中 |
-| **文档质量** | 一般 | 规范详尽但晦涩 | 优秀 | 优秀 |
-| **测试工具** | 少 | SAML Tracer 等 | OAuth Proxy | OIDC Debugger |
-| **预计接入工时** | 1-3 天 | 3-7 天 | 1-3 天 | 1-3 天 |
+| **首次接入工时**（有经验） | 1-2 天 | 3-5 天 | 1-3 天 | 1-3 天 |
+| **首次接入工时**（新手） | 2-3 天 | 5-10 天 | 2-4 天 | 2-4 天 |
+| **主要耗时点** | 逻辑简单，主要是 XML 解析 | XML 解析、签名验证、配置交换 | 理解 Token 生命周期 | 理解 JWT + 流程 |
+| **调试工具** | 浏览器开发者工具 | SAML Tracer（Firefox 插件） | OAuth Proxy、Postman | OIDC Debugger、jwt.io |
+| **Go 库推荐** | 自行实现（逻辑简单） | crewjam/saml | golang.org/x/oauth2（标准库） | coreos/go-oidc |
+
+> [!warning] 工时估算的前提
+> 以上工时假设你已经有了可用的 IdP（如 Keycloak）。如果连 IdP 都要自己搭建和配置，额外增加 1-3 天。
+
+## 混合方案：多协议并存
+
+实际项目中，你很可能不是只用一种协议。常见的混合方案：
+
+**Keycloak 作为统一网关：**
+- 新系统用 OIDC 接入
+- 老系统用 SAML 接入
+- 内部遗留系统用 CAS 接入（Apereo CAS Server 同时支持三种协议）
+- 所有系统共享同一套用户目录（LDAP/AD）
+
+```mermaid
+graph TD
+    LDAP[LDAP / AD 用户目录] --> IdP[统一身份网关<br/>Keycloak / Apereo CAS]
+    IdP -->|OIDC| A[新 Web 应用]
+    IdP -->|OIDC| B[移动端 App]
+    IdP -->|SAML| C[企业客户 SaaS]
+    IdP -->|CAS| D[内部遗留系统]
+```
+
+这种方案的好处是：用户目录统一管理，各系统按自己的节奏迁移协议，不需要一刀切。
 
 ## 推荐开源 IdP
 
-| 产品 | 支持协议 | 特点 | 适用规模 |
-|------|----------|------|----------|
-| **Keycloak** | OIDC, SAML | 功能全面，Red Hat 维护 | 中大型 |
-| **Auth0** | OIDC, SAML | SaaS 托管，上手快 | 中小型 |
-| **Casdoor** | OIDC, SAML, CAS | Go 实现，中文社区 | 中小型 |
-| **Apereo CAS** | CAS, OIDC, SAML | 高校/企业经典选择 | 中大型 |
-| **Authentik** | OIDC, SAML | Python，现代化 UI | 中小型 |
-| **Logto** | OIDC | 开源 Auth0 替代 | 中小型 |
+| 产品 | 协议支持 | 语言 | 特点 | 推荐场景 |
+|------|----------|------|------|----------|
+| **Keycloak** | OIDC、SAML | Java | 功能最全面，Red Hat 维护，社区活跃 | 中大型自建 SSO（首选） |
+| **Auth0** | OIDC、SAML | SaaS 托管 | 零运维，上手最快 | 中小型、快速上线 |
+| **Casdoor** | OIDC、SAML、CAS | Go | 轻量，中文文档友好 | 中小型、Go 技术栈 |
+| **Apereo CAS** | CAS、OIDC、SAML | Java | 高校/企业经典方案 | 有 CAS 遗留的场景 |
+| **Logto** | OIDC | TypeScript | 开源 Auth0 替代，现代化 UI | 中小型 |
 
-> [!tip] Keycloak 是自建 SSO 的首选
-> 如果要自建 SSO 平台，Keycloak 是当前综合评分最高的开源方案。支持 OIDC + SAML，管理界面完善，社区活跃。唯一的缺点是基于 Java，内存占用较大。
+> [!tip] IdP 选型建议
+> - **没有特殊要求** → Keycloak（功能全面、免费、社区大）
+> - **不想运维** → Auth0（SaaS 托管，有免费额度）
+> - **Go 技术栈、想要轻量** → Casdoor
+> - **已有 CAS 基础设施** → Apereo CAS Server 6.x+（同时支持 OIDC/SAML）
 
 ## 关联笔记