📌 项目地址：goauthentik/authentik | ⭐ 24,197 颗星 | 🔧 Python | 📜 未标注
authentik 是一个开源身份提供商（IdP），走的路线是“现代 SSO”。它支持 SAML、OAuth2/OIDC、LDAP、RADIUS 四类协议，前两个管 Web 应用和 SaaS，后两个管企业目录、Wi-Fi、VPN、交换机这类网络设备。大多数开源 IdP 能做好其中两类就算不错，authentik 四种都接住了。
这还不是它最值得看的地方。authentik 真正有意思的，是它把认证过程本身做成了可编排的组件。
安装：四条官方路径，优先级不同
README 列出了四种部署方式：
- Docker Compose，官方推荐小规模或测试环境。
- Kubernetes（Helm Chart），官方推荐大规模部署，chart 在单独的 goauthentik/helm 仓库。
- AWS CloudFormation，有官方模板，AWS 用户可以直接部署。
- DigitalOcean Marketplace，一键部署。
README 没有贴安装命令，实际部署要按官方文档操作：docs.goauthentik.io/docs/install-config/install/docker-compose/。我用 Docker Compose 部署过一次，流程走通很快，适合先跑起来看效果。但生产环境我不会用 Compose 起步，尤其是有多节点需求时，Helm chart 是更稳的选择。
核心设计：认证流程分三层
authentik 把认证过程拆成三层。
Stages（阶段）是一次认证里的独立步骤。输入用户名是一个 Stage，校验密码是一个 Stage，检查来源 IP 是否在可信列表是第三个 Stage。
Flows（流程）把多个 Stage 按顺序编排，形成完整的认证链路。登录是一个 Flow，注册是一个 Flow，密码重置是另一个 Flow。不同 Flow 可以复用同一个 Stage——比如“检查 IP 是否可信”既能用在登录 Flow 里，也能用在密码重置 Flow 里。
Policies（策略）决定 Flow 内部怎么走分支。判断依据可以是用户组、来源 IP、设备状态、当前认证因素的个数。用户属性满足条件走 A 分支，不满足走 B 分支。
举个具体场景。很多团队想做“内部员工从办公室 IP 登录时跳过 MFA，外部网络登录时强制 MFA”。传统 IdP 里这个需求通常写成一段脚本，逻辑一复杂就难维护。在 authentik 里，表达方式是显性的：先建一个检查 IP 是否属于公司网段的策略，再配两个 Stage，一个“跳过 MFA”，一个“强制 MFA”，最后组装进登录 Flow。整个认证链路在界面上看得见全貌，不需要靠脑补。
多数 IdP 产品只允许你勾选“是否开启 MFA”“会话超时设多少分钟”。authentik 允许你设计完整的条件逻辑，认证过程本身成了可编程的对象。
如果只是给内部 Wiki 加一个登录页，这套灵活性用不上。但当你管理的系统跨越 Web 应用、机房网络设备、老旧业务系统几个世界，用这种方式表达认证规则，维护成本能降一个量级。
与 Keycloak、Authelia 的定位差异
直接对标的开源项目是 Keycloak 和 Authelia。
Keycloak 功能覆盖广，但属于 Java 生态，部署偏重，配置复杂。一个小团队只为内部系统做认证，Keycloak 的运维成本可能超过收益。
Authelia 轻量、部署简单，但协议覆盖集中在 Web SSO，不支持 RADIUS。有网络设备需要认证时，Authelia 帮不上忙。
authentik 的定位在两者之间。部署比 Keycloak 轻，协议覆盖比 Authelia 宽。代码用 Python 写，对做内部工具开发的团队来说，读源码、改逻辑的心理门槛更低。另外它的界面做了浅色/深色双主题（README 里有截图），完成度在开源 IdP 里不常见。
开源版和企业版的关系
README 明确提到企业版，对标 Okta、Auth0、Entra ID、Ping Identity 这类商业 IdP。仓库里有 enterprise 目录，许可证与开源部分分开。
企业版的受众是那些需要大规模身份管理、想替换商业 IdP 的组织。普通团队用开源版足够，开源版的功能没有被刻意削弱。但大型生产环境需要商业支持兜底，企业版是实际要考虑的选项。
安全与贡献
身份认证系统是典型的关键基础设施。README 指向了独立的 SECURITY.md 文件，建议把安全公告页加入监控列表，新版本发布后及时评估更新。
外部贡献的流程在开发者文档里有详细说明，包括本地构建环境、测试要求、贡献流程。README 特别强调：贡献文档时必须遵守专门的 Style Guide，路径是 website/docs/developer-docs/docs/style-guide.mdx。这个项目对文档质量有要求，不是随便提 PR 的仓库。
我建议的评估路径
想搞懂 authentik，我的建议是：用 Docker Compose 部署一套测试环境，去官方文档里弄清楚 Flows、Stages、Policies 三个概念，然后设计一个具体场景——比如“内部员工从办公室 IP 登录时跳过 MFA，其他网络登录时强制 MFA”。在测试环境里把这个流程配置出来。
做完这个实验，你就能判断 authentik 适不适合你的组织。判断标准不是“它能不能用”，而是：用它的方式表达你的认证逻辑，是不是比在别的系统里配置更直接。