Authentik 替代品推荐：2026 年中小团队开源 SSO 选型指南

🇺🇸
Read in English: Authentik Alternatives: Choosing an Open Source SSO for Small Teams (2026)

三个月前，一个八人的 SaaS 创业团队在内部论坛上发了一个帖子，标题是”我们到底需不需要自建 SSO”。他们当时已经有了 GitHub OAuth、Google 登录，管理后台用的是硬编码的管理员账号。产品快速迭代，没人觉得这是紧迫问题。直到他们准备接一个企业客户，对方的采购清单第一条就是”支持 SAML 2.0 单点登录”。

这种情况在 20 人以下的技术团队里太常见了。身份认证这件事，要么被推迟，要么被外包给 Auth0、Okta 这类 SaaS 服务，后者每月账单随着用户数增长，到了某个拐点就变成一笔不小的固定支出。开源自托管路线的吸引力在于：一次部署，不按 MAU 收费，数据留在自己手里。

问题是，开源 SSO 工具这几年冒出来不少，光是在 GitHub 上星数过千的就有七八个。Authentik 是其中讨论最多的一个，但它不一定是每个团队的最优解。Keycloak 存在更久，功能最全；Casdoor 走的是轻量路线；Logto 是后起之秀，专门针对开发者体验做了优化。

选哪个，很大程度上取决于你的团队是什么体量、愿意在运维上花多少精力。

Keycloak：老牌，但重

Keycloak 是这个领域的老大哥，Red Hat 出品，2014 年就开始了。功能覆盖范围比 Authentik 还要广，Active Directory 集成、细粒度权限（Fine-Grained Authorization）、多租户，基本上企业能想到的它都有。

代价是资源消耗。Keycloak 基于 Java（WildFly/Quarkus），空载内存占用通常在 500MB 到 800MB 之间（Quarkus 版比旧版轻了不少），但配上数据库和 JVM 预热时间，冷启动体验不友好。在资源受限的环境下跑 Keycloak 需要做额外的 JVM 调优，否则容易 OOM。

管理界面功能强大，但 UI 设计风格一直被吐槽”上世纪感”。2023 年之后推出了新界面，稍好一些，但配置路径还是深。对于没有 Keycloak 经验的工程师，从零配一个完整的 Realm + Client + Role Mapping，可能需要两到三天才能真正弄清楚概念模型。

Keycloak 更适合的场景是：团队有历史遗留的 Java 生态系统、需要对接已有的 LDAP/AD、或者公司里有人曾经用过它。从零开始选型的中小团队，这个学习成本通常不划算。

—

Casdoor：Go 写的，真的轻

Casdoor 的起点不一样。它是 Casbin 团队做的，Casbin 本身是一个权限策略引擎，在 Go 生态里很常见。Casdoor 接管了认证部分，和 Casbin 配合使用能覆盖”认证 + 授权”的完整链路。

资源占用是它的核心卖点：单进程，内存占用通常在 100-200MB 区间，Go 的二进制部署没有 JVM 那种预热问题。一台 1C1G 的小机器跑起来没压力。

协议支持方面，OAuth2、OIDC、SAML 都有，GitHub/Google/微信等第三方登录也内置了。UI 相对简洁，配置项比 Authentik 少，这对于只需要标准功能的团队反而是优点，不需要在一堆不会用到的选项里找路。

局限在哪？Casdoor 的企业级功能相对薄弱，细粒度的 Policy Engine、复杂的 Webhook 触发逻辑这类需求，它做得不如 Authentik 丰富。社区规模比 Authentik 和 Keycloak 小，遇到偏门问题时 GitHub Issues 和 Stack Overflow 上的参考案例会少一些。

如果团队的需求就是”我需要一个能跑 OAuth2/OIDC 的 SSO，支持几十到几百个内部用户，不想花太多运维精力”，Casdoor 是被低估的选项。

—

Logto：为开发者体验而生

Logto 是这四个里最年轻的，2022 年才开始，但增速很快。它的设计理念一开始就是”Auth0 的开源替代品”，所以 DX（开发者体验）是优先级最高的事情。

最直观的体现是 SDK：Logto 的前端 SDK 覆盖 React、Vue、Next.js、Angular，后端覆盖 Node.js、Python、Go、Java，每个 SDK 都有详细文档和 Quickstart。一个没有 IAM 背景的工程师，按着 Quickstart 走，两小时内能把 OIDC 登录集成进自己的应用。

登录界面也是一个亮点：Logto 内置了一个可定制的登录 UI，不需要自己写登录页，改个 logo 和颜色就能用。对于 MVP 阶段的产品来说，这省掉了相当多的前端工作量。

资源占用中等，Node.js 的进程加上 PostgreSQL 依赖，内存需求大概在 300-500MB 区间。部署比 Authentik 简单，Docker Compose 启动后管理界面的引导流程做得很顺手。

问题是 SAML 2.0 支持。Logto 的 SAML IdP 功能是在 2024 年之后才逐渐完善的，如果企业客户要求的是老式的 SAML SP-initiated SSO，需要确认当前版本的支持状态。SCIM 自动化用户同步也是相对新的功能，稳定性比 Authentik 或 Keycloak 弱一些。

—

四个工具横向对比

把核心维度并排放，更容易看出差距在哪：

	Authentik	Keycloak	Casdoor	Logto
最低内存（含依赖）	~800MB	~600MB	~150MB	~400MB
部署难度	中	高	低	低-中
SAML 支持	完整	完整	基础	逐步完善
SCIM 支持	有	有	N/A	有（较新）
开发者 SDK	有限	有限	有限	丰富
自定义登录 UI	需自建	需自建	基础模板	内置可定制
社区活跃度	高	高	中	中高
学习曲线	中-高	高	低	低-中

这张表是粗粒度的，实际选型还要看具体场景。

—

不同场景的选择建议

场景一：接企业客户，对方要求 SAML，团队有人愿意花时间配置

选 Authentik。它的 SAML 实现最成熟，遇到企业客户挑剔的 SP 配置（比如加密断言、自定义属性映射）时，Authentik 的文档和社区能给到足够的支持。资源成本摊到一台独立的小云主机上，每月也就几十块钱。

场景二：资源极度受限，或者想在现有服务器上塞一个 SSO 进去

选 Casdoor。用 Go 写的，内存占用是这四个里最小的，运维成本也低。如果需求是标准的 OAuth2/OIDC，没有特别复杂的权限策略，Casdoor 能做的事情足够。

场景三：产品还在 MVP 阶段，团队里没有 IAM 经验，想快速集成登录功能

选 Logto。SDK 文档完整，开发体验好，内置登录 UI 省掉前端工作量。等产品规模上来后，再考虑是否迁移到功能更全的方案，那时候已经有足够的信息做决策了。

场景四：Java 技术栈，有历史遗留系统需要对接 LDAP/AD，或者团队有 Keycloak 经验

选 Keycloak。不是因为它最好，而是因为生态匹配，Java 应用对 Keycloak 的适配器支持最完整，已有经验的人能绕过大部分学习成本。

有一种情况值得单独说：如果团队规模增长到 50 人以上、开始有多租户需求、或者需要对用户做精细化权限分组，Authentik 的 Policy Engine 和 Group 机制会比 Logto 和 Casdoor 更有余量。这不是说其他工具不能做，而是 Authentik 在这个方向上的设计更系统，扩展起来摩擦更少。

—

开源 SSO 选型没有唯一正确答案，但有一个错误选择：把”功能最全”和”适合我们”画等号。Keycloak 功能最全，但它的学习成本和资源开销不是每个团队都愿意承担的。对一个五人团队来说，一个配置简单、能稳定跑起来的 Casdoor，比一个功能强大但永远配不好的 Keycloak 有用得多。

工具选对了，才值得花精力深挖。