Files
Qiniu/technical/sso/sso-comparison.md
T

155 lines
6.7 KiB
Markdown
Raw Normal View History

2026-07-13 10:08:46 +08:00
---
tags: [sso, architecture, auth]
create time: 2026-07-13 10:03
---
# SSO 协议对比与选型指南
2026-07-13 11:11:37 +08:00
## TL;DR
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
> **不知道选什么?选 OIDC。** 它是当前最通用的 SSO 协议,支持 Web、移动端、SPA,生态最好,学习资源最丰富。
>
> 只有在以下情况才考虑其他协议:
> - 客户要求 SAML 对接 → 用 **SAML 2.0**
> - 只有内部 Web 系统、已有 CAS 基础设施 → 用 **CAS**
> - 不需要认证,只需要 API 授权 → 用 **OAuth 2.0**
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
## 四种协议一览
2026-07-13 10:08:46 +08:00
| 维度 | CAS | SAML 2.0 | OAuth 2.0 | OIDC |
|------|-----|----------|-----------|------|
2026-07-13 11:11:37 +08:00
| **一句话定位** | 内网 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 坑多) | 中 | 中 |
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
## 什么时候该选哪个?
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
### OIDC — 默认选择
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
- ✅ 新项目、没有特殊约束
- ✅ 需要支持移动端、SPA、微服务
- ✅ 要对接 Keycloak、Auth0、Azure AD 等现代 IdP
- ✅ 需要标准化的用户信息接口
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
### SAML 2.0 — 企业客户要求时
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
- ✅ 客户的 IT 部门只提供 SAML IdP(AD FS、Okta)
- ✅ B2B SaaS 产品,客户要求 SAML 集成
- ✅ 合规要求(FedRAMP、SOC 2)强制 SAML
- ⚠️ 可以同时支持 OIDC + SAML(Keycloak 两者都支持)
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
### CAS — 遗留系统 / 简单场景
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
- ✅ 企业内网几个传统 Web 系统需要统一登录
- ✅ 已有 Apereo CAS Server 基础设施
- ✅ 团队不熟悉 OAuth/JWT,需要快速落地
- ❌ 不适合移动端、SPA、第三方接入
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
### OAuth 2.0 — 只需要授权,不需要认证
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
- ✅ 第三方应用需要访问你的 API(如「用微信登录」)
- ✅ 服务间调用(M2M),用客户端凭证模式
- ⚠️ 如果需要知道「用户是谁」,请用 OIDC(OAuth 2.0 不提供用户身份信息)
2026-07-13 10:08:46 +08:00
## 选型决策树
```mermaid
graph TD
2026-07-13 11:11:37 +08:00
A[需要 SSO] --> B{有移动端或 SPA?}
B -->|是| C[OIDC ✅]
B -->|否| D{需要对接企业客户 IdP?}
D -->|是| E{客户要求什么协议?}
2026-07-13 10:08:46 +08:00
E -->|SAML| F[SAML 2.0]
2026-07-13 11:11:37 +08:00
E -->|OIDC 或无要求| C
D -->|否| G{只是内部 Web 系统?}
G -->|是| H{已有 CAS 基础设施?}
H -->|有| I[CAS]
H -->|没有| C
G -->|否| J{第三方 API 授权?}
2026-07-13 10:08:46 +08:00
J -->|是| K[OAuth 2.0]
J -->|否| C
```
2026-07-13 11:11:37 +08:00
## 数据格式与签名
| 格式 | 说明 | 优点 | 缺点 |
|------|------|------|------|
| **XML**(SAML/CAS) | 2000 年代企业标准 | 工具链成熟、标准严谨 | 冗长、解析慢、安全坑多(如 XML Signature Wrapping) |
| **JSON**(OAuth 2.0) | 无 Token 结构约束 | 轻量、开发者友好 | 需要自行定义 Token 格式 |
| **JWT**(OIDC) | JSON + 签名 | 自包含、可离线验证、标准统一 | Payload 可见(非加密)、无法即时撤销 |
**签名能力对比:**
2026-07-13 10:08:46 +08:00
2026-07-13 11:11:37 +08:00
| 协议 | 签名 | 加密 | 说明 |
|------|------|------|------|
| 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 加密。
## 接入成本对比
2026-07-13 10:08:46 +08:00
| 维度 | CAS | SAML | OAuth 2.0 | OIDC |
|------|-----|------|-----------|------|
2026-07-13 11:11:37 +08:00
| **首次接入工时**(有经验) | 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[内部遗留系统]
```
这种方案的好处是:用户目录统一管理,各系统按自己的节奏迁移协议,不需要一刀切。
2026-07-13 10:08:46 +08:00
## 推荐开源 IdP
2026-07-13 11:11:37 +08:00
| 产品 | 协议支持 | 语言 | 特点 | 推荐场景 |
|------|----------|------|------|----------|
| **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] IdP 选型建议
> - **没有特殊要求** → Keycloak(功能全面、免费、社区大)
> - **不想运维** → Auth0(SaaS 托管,有免费额度)
> - **Go 技术栈、想要轻量** → Casdoor
> - **已有 CAS 基础设施** → Apereo CAS Server 6.x+(同时支持 OIDC/SAML)
2026-07-13 10:08:46 +08:00
## 关联笔记
- [[sso/sso-oauth2|OAuth 2.0 授权码模式]]
- [[sso/sso-oidc|OpenID Connect (OIDC)]]
- [[sso/sso-saml|SAML 2.0]]
- [[sso/sso-cas|CAS 协议]]
- [[sso|SSO 单点登录(主文档)]]