authentik 凭什么替代 Okta？自托管统一登录从自建应用到团队

翻一下自建玩家的密码管理器，大概率会看到这样的清单：Grafana 一套账号、Gitea 一套、NAS 管理页一套、路由器后台又一套。放到团队里，麻烦更直接：新人入职要逐个系统开账号；人离职后漏收一个入口，就是一次安全事故。

密码管理器能帮你“记住”账号，却管不了权限怎么发、怎么收，也不管有没有二次验证。身份安全领域对这类问题早有标准答案：身份提供方（IdP）。应用不再各自维护登录，统一把用户交给 IdP 验证。企业市场里这个位置长期被 Okta、Auth0、微软 Entra ID 占据，按人头收费，数据也留在厂商手里。

开源世界并非没有替代品，但长期两端分化：Keycloak 功能全、生态老，代价是 Java 栈的运维负担和出了名的学习曲线；Authelia 一类轻量方案上手快，协议覆盖却窄，不支持 SAML，接不了遗留系统。中间地带一直空着，直到 authentik 出现。

项目卡片

• 项目：authentik[1]
• 状态：24.5k Star / 稳定版 2026.5.6 / 季度发版，2026.8 已获 OpenID 基金会官方认证
• 一句话判断：目前协议覆盖最全、对自托管最友好的开源 IdP，个人玩家和想摆脱 Okta 的团队各有入口

它凭什么站在中间地带

评价一款身份软件，我一般先问三个问题：协议覆盖多广、实现是否可信、有没有人长期维护。

第一个问题，官方 README 给出了答案：它是面向现代 SSO 的开源 IdP，“从小型实验室到大型生产集群”都能自托管。协议清单覆盖 SAML、OAuth2/OIDC、LDAP、RADIUS、SCIM，外加一个专用于兜底的代理认证，几乎一次打尽了企业遗留系统和个人自建应用两套认证协议。

可信度则有一个更硬的佐证。2026 年 8 月的发布说明显示，authentik 通过了 OpenID 基金会的 OpenID Certified 认证，覆盖全部五种 OpenID Provider profile 和三种登出 profile。这是第三方对 OIDC 实现规范性的官方背书，也让它与那些“自己照规范实现一遍”的项目拉开了差距。

长期维护看发版记录。这个项目 2019 年底创建，至今保持季度发版（2、5、8、11 月），最近两个大版本持续获得安全维护。身份软件最怕停更，毕竟你把全公司登录都押在上面，维护方的节奏就是它的信用。

场景一：自建应用玩家的统一门卫

先看最小的场景。自建玩家的要求不高：一次登录，进所有应用。

支持 OIDC 或 SAML 的应用走标准协议接入，官方 integrations 站点收录了 180 多篇指南，Grafana、Gitea、Immich、Jellyfin、群晖这些 homelab 常客都有现成步骤。更关键的是另一半现实：自建应用里总有几个老应用根本不支持 SSO。authentik 的 proxy provider 在反向代理层做认证检查，应用一行代码不用改，未登录就被弹到统一登录页；认证通过后，它还会把用户名、组信息以请求头方式注入后端，应用愿意接就可以直接读。

体验上还有一个容易被忽略的入口：用户面板把所有接入应用汇成一面启动墙，点图标即登录，界面上还能配置 TOTP、WebAuthn 安全密钥等二次验证。登录来源也不止用户名密码，GitHub、Google、微信、Telegram 等 18 种社交登录源都是现成的。对个人用户来说，这相当于给全部自建应用免费加了一道 MFA。

场景二：想摆脱按人头计费的团队

场景放大到企业，authentik 的 README 写得非常直白：商业版瞄准的就是替换 Okta、Auth0、Entra ID、Ping Identity。

动机很好理解。商业 IdP 按用户数收费，团队从 50 人涨到 500 人，账单也随之涨十倍；身份数据放在厂商手里，合规上始终隔着一层。authentik 则给出另一条路线：核心功能采用 MIT 许可自托管，数据留在自己机房，用户数不设上限。2026.8 版本甚至加入了 token 交换和密钥绑定令牌这类防令牌窃取的企业级特性。

更值得说的是它的商业模式边界，这条线画得比很多人预想的大方。免费侧包括：全协议 SSO、MFA、代理认证，连通过 Web 访问 RDP/SSH 远程终端都免费；付费侧，仓库里的 authentik/enterprise/ 目录单独使用 EE 许可，收录 Google Workspace/Entra 同步、WS-Fed、增强审计这类企业刚需。真正让我改观的，是官方 FAQ 里的这条承诺：开源版已有功能永远不会转为企业专属，只允许企业功能反向下放到开源。对担心项目“养肥了再杀”的自托管用户来说，这句话比任何许可证文本都实在。

价值之外，把边界也说清

它不是没有代价，而且代价都写在明处。

升级文档开头就是红色警告：不支持降级，升级前必须备份 PostgreSQL，大版本不能跳级升，server 和 outpost 版本必须保持一致。每次升级都是一次需要认真对待的运维操作。官方也不提供托管版，不想碰运维的话，最接近的折中方案是 DigitalOcean 一键镜像。部署入口本身是分层的：个人玩家用 Docker Compose 就够，团队推荐 Kubernetes Helm chart，AWS 上还有官方 CloudFormation 模板。开源版同样没有工单支持，遇到深水区只能靠文档和社区 Discord。

还有一层隐性成本：authentik 把登录流程拆成 flow、stage、policy 三层积木，这是它自由的来源，也是学习成本的来源。只接几个应用、使用默认配置时，你几乎感知不到这层抽象；真要深度定制，得先花时间理解这套模型。

这些代价我倒不认为是减分项。身份软件本就该把风险摆在明处，敢把“不支持降级”写进文档的项目，比什么都承诺的项目可信。

判断标准因此很清晰：如果你想给自建应用统一登录并加 MFA，或团队想用自托管替代按人头收费的商业 IdP，它是当前开源选项里协议最全、入口最友好的一个。但若你需要的是零运维托管服务，或团队没人愿意碰身份系统的运维细节，商业托管 IdP 仍然更合适。至于你自己愿不愿意接下身份系统的运维责任，这篇文章没法替你回答。

引用链接

• [1] authentik: https://github.com/goauthentik/authentik