ropean 一、主流开源 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 技术栈全景图
┌────────────────────────────────────────────────────────┐
│ Casdoor │
├───────────┬────────────────────────────────────────────┤
│ AI 网关 │ MCP Gateway · A2A Protocol │
├───────────┼────────────────────────────────────────────┤
│ 认证协议 │ OAuth 2.1 · OIDC · SAML · CAS │
├───────────┼────────────────────────────────────────────┤
│ 目录同步 │ LDAP · SCIM │
├───────────┼────────────────────────────────────────────┤
│ MFA │ WebAuthn · TOTP · Face ID │
├───────────┼────────────────────────────────────────────┤
│ 企业 IdP │ Google Workspace · Azure AD · 微信 · 钉钉 │
├───────────┼────────────────────────────────────────────┤
│ 权限引擎 │ Casbin (RBAC / ABAC / ACL) │
└───────────┴────────────────────────────────────────────┘---
三、Casdoor vs Authentik 深度对比
Authentik 是另一个热门的现代化 SSO 方案，以下从几个关键维度做对比。
认证流程定制
这是两者最大的差异点。
Authentik 的核心优势是可视化的 Flow Designer，可以像画流程图一样编排认证步骤，支持条件分支：
登录 → 检查是否企业邮箱
→ 是 → 跳转 SAML IdP（企业 SSO）
→ 否 → 密码输入 → 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 + 身份认证层**
OAuth 2.0：
用户授权 → Access Token（能访问哪些资源）OIDC：
用户授权 → 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 原理简述：
应用生成随机 code_verifier → 算出 code_challenge → 发给授权服务器
授权服务器返回 authorization code
应用拿 code + code_verifier 换 token
授权服务器验证 code_verifier 是否匹配→ 即使攻击者截获了 code，没有 code_verifier 也无法换取 token
`
4.3 OIDC 与 SSO 的关系
SSO (Single Sign-On) 是一个用户体验目标——登录一次，访问多个应用。 OIDC 是实现这个目标的技术手段之一。
SSO 是目标，OIDC 是实现手段。
没有 SSO：每个应用都要单独登录
有 SSO： 登录一次，所有应用自动通行实现 SSO 的技术手段有多种：
| 技术 | 年代 | 现状 |
|---|---|---|
| CAS | 2004 | 仍在用，偏老旧 |
| SAML 2.0 | 2005 | 企业中仍广泛使用 |
| **OIDC** | **2014** | **当前主流** |
OIDC 实现 SSO 的核心原理：
Casdoor（OIDC Provider，维护中心 Session）
│
用户在这里登录一次，建立 Session
│
┌───────────┼───────────┐
↓ ↓ ↓
App A App B App C- 访问 App A → 重定向到 Casdoor → 输入密码 → 登录成功
- 访问 App B → 重定向到 Casdoor → Session 还在 → 自动登录 ✓
- 访问 App C → 同理 → 自动登录 ✓
- ```
类比：SSO 就像"一卡通"——刷一次卡，食堂、图书馆、宿舍都能进。OIDC 是这张卡的技术标准（芯片类型、通信协议、数据格式），而 Casdoor/Keycloak 则是发卡和验卡的管理中心。
---
五、关于 Authelia 的补充
Authelia 是一个轻量级的认证中间件，其核心架构是作为反向代理的 Forward Auth 组件。
用户 → 反向代理（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 方案，尚在早期阶段，暂未公开。