134 lines
4.9 KiB
Markdown
134 lines
4.9 KiB
Markdown
---
|
||
tags: [sso, architecture, auth]
|
||
create time: 2026-07-13 10:03
|
||
---
|
||
|
||
# SSO 协议对比与选型指南
|
||
|
||
## 概述
|
||
|
||
本文横向对比 CAS、SAML 2.0、OAuth 2.0、OIDC 四种主流 SSO 协议，帮助你在实际项目中做出合理的选型决策。
|
||
|
||
## 横向对比总览
|
||
|
||
| 维度 | 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/移动应用 |
|
||
|
||
## 各协议适用场景
|
||
|
||
### 选择 CAS 的场景
|
||
|
||
- 企业内部多个传统 Web 系统需要统一登录
|
||
- 已有 Apereo CAS Server 基础设施
|
||
- 团队对 OAuth/JWT 不熟悉，需要快速落地
|
||
- 不涉及移动端或第三方接入
|
||
|
||
### 选择 SAML 2.0 的场景
|
||
|
||
- 与企业客户的 IdP（AD FS、Okta）对接
|
||
- 已有 AD/LDAP 用户体系，需要对外暴露 SSO
|
||
- B2B SaaS 产品，客户要求 SAML 集成
|
||
- 合规要求（如 FedRAMP、SOC 2）强制使用 SAML
|
||
|
||
### 选择 OAuth 2.0 的场景
|
||
|
||
- 第三方应用需要有限度地访问你的 API
|
||
- 「用微信/GitHub 登录」这类需求
|
||
- 纯 API 服务的访问控制（客户端凭证模式）
|
||
- 服务间的 M2M 认证
|
||
|
||
### 选择 OIDC 的场景
|
||
|
||
- **新项目的首选**——现代、通用、生态好
|
||
- 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 加密。
|
||
|
||
## 选型决策树
|
||
|
||
```mermaid
|
||
graph TD
|
||
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{第三方授权?}
|
||
J -->|是| K[OAuth 2.0]
|
||
J -->|否| C
|
||
```
|
||
|
||
> [!tip] 默认选 OIDC
|
||
> 如果你没有强烈的理由选择其他协议，**OIDC 是最安全的默认选择**。它覆盖了 SSO + 授权的完整场景，生态支持最好，学习资源最丰富。
|
||
|
||
## 接入成本评估
|
||
|
||
| 维度 | CAS | SAML | OAuth 2.0 | OIDC |
|
||
|------|-----|------|-----------|------|
|
||
| **Go 库成熟度** | 一般 | 一般 | 优秀 | 优秀 |
|
||
| **调试难度** | 低 | 高（XML 解析坑多） | 中 | 中 |
|
||
| **文档质量** | 一般 | 规范详尽但晦涩 | 优秀 | 优秀 |
|
||
| **测试工具** | 少 | SAML Tracer 等 | OAuth Proxy | OIDC Debugger |
|
||
| **预计接入工时** | 1-3 天 | 3-7 天 | 1-3 天 | 1-3 天 |
|
||
|
||
## 推荐开源 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 替代 | 中小型 |
|
||
|
||
> [!tip] Keycloak 是自建 SSO 的首选
|
||
> 如果要自建 SSO 平台，Keycloak 是当前综合评分最高的开源方案。支持 OIDC + SAML，管理界面完善，社区活跃。唯一的缺点是基于 Java，内存占用较大。
|
||
|
||
## 关联笔记
|
||
|
||
- [[sso/sso-oauth2|OAuth 2.0 授权码模式]]
|
||
- [[sso/sso-oidc|OpenID Connect (OIDC)]]
|
||
- [[sso/sso-saml|SAML 2.0]]
|
||
- [[sso/sso-cas|CAS 协议]]
|
||
- [[sso|SSO 单点登录（主文档）]]
|