一、主流开源 SSO 方案概览

方案语言协议覆盖自带 UI部署复杂度适合规模
KeycloakJava最全（OIDC, OAuth 2.0, SAML）完善中中大型企业
AutheliaGoOIDC, OAuth 2.0有低小中型/自托管
AuthentikPython + GoOIDC, OAuth 2.0, SAML, SCIM现代化中中型
CasdoorGo + ReactOAuth 2.1, OIDC, SAML, CAS, SCIM完善低中型/全平台
OryGoOIDC, OAuth 2.0无 (Headless)中需要高度定制
DexGoOIDC无低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.1OAuth 2.0 的安全加固版，强制 PKCE、移除隐式授权等不安全模式
OIDC (OpenID Connect)基于 OAuth 2.0 的身份认证层，获取用户身份信息的标准协议
SAML 2.0企业级联邦身份认证协议，广泛用于企业 SSO
CAS经典单点登录协议，常见于教育机构和老系统

3. 目录与用户同步

协议说明
LDAP对接企业 AD/LDAP 目录服务
SCIM跨域用户身份自动同步，实现用户/组的自动化 provisioning/deprovisioning

4. 多因素认证 (MFA)

方式说明
WebAuthnW3C 标准，支持硬件安全密钥和平台认证器
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+，偏向国际化平台。

部署与资源

AuthentikCasdoor
依赖PostgreSQL + RedisMySQL/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.0OIDC
酒店的房卡（能进哪个房间）酒店的房卡 + 身份证（你是谁 + 能进哪个房间）

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 的技术手段有多种：

技术年代现状
CAS2004仍在用，偏老旧
SAML 2.02005企业中仍广泛使用
OIDC2014当前主流

OIDC 实现 SSO 的核心原理：

          Casdoor（OIDC Provider，维护中心 Session）
                    │
         用户在这里登录一次，建立 Session
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     App A        App B       App C
  1. 访问 App A → 重定向到 Casdoor → 输入密码 → 登录成功
  2. 访问 App B → 重定向到 Casdoor → Session 还在 → 自动登录 ✓
  3. 访问 App C → 同理 → 自动登录 ✓
  4. `

类比：SSO 就像"一卡通"——刷一次卡，食堂、图书馆、宿舍都能进。OIDC 是这张卡的技术标准（芯片类型、通信协议、数据格式），而 Casdoor/Keycloak 则是发卡和验卡的管理中心。

---

五、关于 Authelia 的补充

Authelia 是一个轻量级的认证中间件，其核心架构是作为反向代理的 Forward Auth 组件。

用户 → 反向代理（Nginx/Traefik/Caddy）→ Authelia 验证 → 后端应用
  • 它依赖反向代理来拦截请求，但反向代理本身就是生产环境的标配组件
  • 认证逻辑完全由 Authelia 自己处理，不依赖外部认证服务
  • 从 v4.29 起也支持作为 OIDC Provider，应用可通过标准协议获取 Token
  • 但整体功能偏轻量，适合"够用就好"的场景

---

六、总结

选择 SSO 方案的核心考量：

  1. 用户群体：国内用户优先考虑 Casdoor（社交登录支持最全）
  2. 部署资源：资源有限选 Casdoor 或 Authelia（Go 单二进制，轻量）
  3. 功能需求：需要复杂流程编排选 Authentik，需要企业级全家桶选 Keycloak
  4. AI 场景：需要 MCP/A2A 网关能力，Casdoor 目前是唯一的开源选择
  5. 协议覆盖：需要 SAML + CAS 兼容老系统，Casdoor 和 Keycloak 都能满足
  6. 开源协议：在意纯开源选 Casdoor（Apache 2.0）

---

目前我正在开发 Serverless 版本的 SSO 方案，尚在早期阶段，暂未公开。