ropean #开源 SSO 方案选型指南：从协议到落地
#一、主流开源 SSO 方案概览
| 方案 | 语言 | 协议覆盖 | 自带 UI | 部署复杂度 | 适合规模 |
|---|---|---|---|---|---|
| Keycloak | Java | 最全（OIDC, OAuth 2.0, SAML） | 完善 | 中 | 中大型企业 |
| Authelia | Go | OIDC, OAuth 2.0 | 有 | 低 | 小中型/自托管 |
| Authentik | Python + Go | OIDC, OAuth 2.0, SAML, SCIM | 现代化 | 中 | 中型 |
| Casdoor | Go + React | OAuth 2.1, OIDC, SAML, CAS, SCIM | 完善 | 低 | 中型/全平台 |
| Ory | Go | OIDC, OAuth 2.0 | 无 (Headless) | 中 | 需要高度定制 |
| Dex | Go | OIDC | 无 | 低 | Kubernetes 环境 |
简要推荐：
- 企业级全功能 → Keycloak
- 轻量自托管 → Authelia
- 现代化体验、灵活流程编排 → Authentik
- 国内项目、多平台、AI 场景 → Casdoor
- 高度定制、API-first → Ory
- Kubernetes 原生 → Dex
#二、重点方案：Casdoor
Casdoor 定位为 AI-first 的 Identity and Access Management (IAM) 平台，由 Casbin 社区（中国团队）维护，采用 Apache 2.0 开源协议。
#技术能力全景
#1. AI 相关
| 技术 | 说明 |
|---|---|
| MCP (Model Context Protocol) | Anthropic 提出的 AI 模型上下文协议，Casdoor 可作为 MCP Gateway，统一管理 AI Agent 的身份和权限 |
| A2A (Agent-to-Agent) | Google 提出的 Agent 间通信协议，支持 AI Agent 之间的安全身份验证和授权 |
#2. 认证协议
| 协议 | 说明 |
|---|---|
| OAuth 2.1 | OAuth 2.0 的安全加固版，强制 PKCE、移除隐式授权等不安全模式 |
| OIDC (OpenID Connect) | 基于 OAuth 2.0 的身份认证层，获取用户身份信息的标准协议 |
| SAML 2.0 | 企业级联邦身份认证协议，广泛用于企业 SSO |
| CAS | 经典单点登录协议，常见于教育机构和老系统 |
#3. 目录与用户同步
| 协议 | 说明 |
|---|---|
| LDAP | 对接企业 AD/LDAP 目录服务 |
| SCIM | 跨域用户身份自动同步，实现用户/组的自动化 provisioning/deprovisioning |
#4. 多因素认证 (MFA)
| 方式 | 说明 |
|---|---|
| WebAuthn | W3C 标准，支持硬件安全密钥和平台认证器 |
| TOTP | 基于时间的一次性密码，兼容 Google Authenticator 等 |
| Face ID | 面部识别，移动端生物特征认证 |
#5. 企业身份源
| 身份源 | 说明 |
|---|---|
| Google Workspace | 对接 Google 企业账号 |
| Azure AD (Entra ID) | 对接微软企业账号 |
| 微信 / 企业微信 / 钉钉 / 飞书 | 国内主流平台原生支持 |
#6. 权限引擎
与 Casbin 深度集成，支持 RBAC、ABAC、ACL 等多种权限模型，覆盖 Go、Java、Node、Python 等多语言 SDK。
#Casdoor 技术栈全景图
1┌────────────────────────────────────────────────────────┐
2│ Casdoor │
3├───────────┬────────────────────────────────────────────┤
4│ AI 网关 │ MCP Gateway · A2A Protocol │
5├───────────┼────────────────────────────────────────────┤
6│ 认证协议 │ OAuth 2.1 · OIDC · SAML · CAS │
7├───────────┼────────────────────────────────────────────┤
8│ 目录同步 │ LDAP · SCIM │
9├───────────┼────────────────────────────────────────────┤
10│ MFA │ WebAuthn · TOTP · Face ID │
11├───────────┼────────────────────────────────────────────┤
12│ 企业 IdP │ Google Workspace · Azure AD · 微信 · 钉钉 │
13├───────────┼────────────────────────────────────────────┤
14│ 权限引擎 │ Casbin (RBAC / ABAC / ACL) │
15└───────────┴────────────────────────────────────────────┘#三、Casdoor vs Authentik 深度对比
Authentik 是另一个热门的现代化 SSO 方案，以下从几个关键维度做对比。
#认证流程定制
这是两者最大的差异点。
Authentik 的核心优势是可视化的 Flow Designer，可以像画流程图一样编排认证步骤，支持条件分支：
1登录 → 检查是否企业邮箱
2 → 是 → 跳转 SAML IdP（企业 SSO）
3 → 否 → 密码输入 → MFA → 登录成功Casdoor 的认证流程相对固定，通过配置项调整，不支持复杂的条件分支编排。
#社交登录
Casdoor 支持 40+ 社交登录提供商，特别是微信、企业微信、钉钉、飞书、支付宝等国内平台原生支持。Authentik 约 20+，偏向国际化平台。
#部署与资源
| Authentik | Casdoor | |
|---|---|---|
| 依赖 | PostgreSQL + Redis | MySQL/PostgreSQL/SQLite 可选 |
| 资源占用 | 较高（Django + Go 双进程） | 较低（单一 Go 二进制） |
| 数据库灵活性 | 仅 PostgreSQL | 多种可选 |
#应用代理
Authentik 内置 Forward Auth / 应用代理能力（类似 Authelia），可以在不修改应用代码的情况下保护 Web 应用。Casdoor 不具备此能力，所有应用必须通过 SDK 集成。
#SDK 生态
Casdoor 的 SDK 覆盖面远超 Authentik：Go、Java、Node、Python、PHP、.NET、Rust、Dart/Flutter、React、Vue、Angular、Swift、uni-app 等。特别是移动端和前端框架的支持非常全面。
#权限控制
Casdoor 与 Casbin 深度集成，支持细粒度的 API 级权限控制。Authentik 的权限更偏向"谁能访问哪个应用"的层面。
#选型建议
- 需要灵活认证流程编排、Forward Auth → Authentik
- 国内用户、多平台 SDK、轻量部署、AI 场景 → Casdoor
#四、认证协议核心概念
#4.1 OAuth 2.0 vs OIDC
OAuth 2.0 是授权协议（Authorization），解决"允许第三方应用访问我的资源"的问题，产出物是 Access Token。它不关心"你是谁"，只关心"你能做什么"。
OIDC (OpenID Connect) 是认证协议（Authentication），建立在 OAuth 2.0 之上，额外提供用户身份信息。
OIDC = OAuth 2.0 + 身份认证层
1OAuth 2.0：
2 用户授权 → Access Token（能访问哪些资源）
3
4OIDC：
5 用户授权 → Access Token + ID Token（JWT，包含用户身份：email, name 等）OIDC 在 OAuth 2.0 基础上新增了：
- ID Token：JWT 格式，包含用户身份声明（sub, email, name, picture 等）
- UserInfo Endpoint：
/userinfo接口查询用户详细信息 - 标准化 Claims：统一的用户属性命名
- Discovery：
.well-known/openid-configuration自动发现端点配置 - Session 管理：标准化的登录/登出流程
类比理解：
| OAuth 2.0 | OIDC |
|---|---|
| 酒店的房卡（能进哪个房间） | 酒店的房卡 + 身份证（你是谁 + 能进哪个房间） |
#4.2 OAuth 2.1 是什么
OAuth 2.1 不是全新协议，而是 OAuth 2.0 的安全加固版——把多年来的最佳实践和安全补丁整合到一个版本中。
删掉的不安全功能：
| 被移除的功能 | 风险 |
|---|---|
| Implicit Grant（隐式授权） | Token 直接暴露在 URL 中，容易被截获 |
| Resource Owner Password Grant（密码模式） | 用户把密码直接交给第三方应用 |
| Token 放在 URL 查询参数中 | 会被浏览器历史、日志、Referer 头泄露 |
强制的安全措施：
| 强制要求 | 说明 |
|---|---|
| PKCE | 所有客户端必须使用，防止授权码被截获后冒用 |
| Redirect URI 精确匹配 | 防止重定向攻击 |
| Refresh Token 限制 | 绑定客户端或一次性使用 |
PKCE 原理简述：
1应用生成随机 code_verifier → 算出 code_challenge → 发给授权服务器
2授权服务器返回 authorization code
3应用拿 code + code_verifier 换 token
4授权服务器验证 code_verifier 是否匹配
5
6→ 即使攻击者截获了 code，没有 code_verifier 也无法换取 token#4.3 OIDC 与 SSO 的关系
SSO (Single Sign-On) 是一个用户体验目标——登录一次，访问多个应用。 OIDC 是实现这个目标的技术手段之一。
SSO 是目标，OIDC 是实现手段。
1没有 SSO：每个应用都要单独登录
2有 SSO： 登录一次，所有应用自动通行实现 SSO 的技术手段有多种：
| 技术 | 年代 | 现状 |
|---|---|---|
| CAS | 2004 | 仍在用，偏老旧 |
| SAML 2.0 | 2005 | 企业中仍广泛使用 |
| OIDC | 2014 | 当前主流 |
OIDC 实现 SSO 的核心原理：
1 Casdoor（OIDC Provider，维护中心 Session）
2 │
3 用户在这里登录一次，建立 Session
4 │
5 ┌───────────┼───────────┐
6 ↓ ↓ ↓
7 App A App B App C
8
91. 访问 App A → 重定向到 Casdoor → 输入密码 → 登录成功
102. 访问 App B → 重定向到 Casdoor → Session 还在 → 自动登录 ✓
113. 访问 App C → 同理 → 自动登录 ✓类比：SSO 就像"一卡通"——刷一次卡，食堂、图书馆、宿舍都能进。OIDC 是这张卡的技术标准（芯片类型、通信协议、数据格式），而 Casdoor/Keycloak 则是发卡和验卡的管理中心。
#五、关于 Authelia 的补充
Authelia 是一个轻量级的认证中间件，其核心架构是作为反向代理的 Forward Auth 组件。
1用户 → 反向代理（Nginx/Traefik/Caddy）→ Authelia 验证 → 后端应用- 它依赖反向代理来拦截请求，但反向代理本身就是生产环境的标配组件
- 认证逻辑完全由 Authelia 自己处理，不依赖外部认证服务
- 从 v4.29 起也支持作为 OIDC Provider，应用可通过标准协议获取 Token
- 但整体功能偏轻量，适合"够用就好"的场景
#六、总结
选择 SSO 方案的核心考量：
- 用户群体：国内用户优先考虑 Casdoor（社交登录支持最全）
- 部署资源：资源有限选 Casdoor 或 Authelia（Go 单二进制，轻量）
- 功能需求：需要复杂流程编排选 Authentik，需要企业级全家桶选 Keycloak
- AI 场景：需要 MCP/A2A 网关能力，Casdoor 目前是唯一的开源选择
- 协议覆盖：需要 SAML + CAS 兼容老系统，Casdoor 和 Keycloak 都能满足
- 开源协议：在意纯开源选 Casdoor（Apache 2.0）
目前我正在开发 Serverless 版本的 SSO 方案，尚在早期阶段，暂未公开。