Authelia vs authentik：自托管单点登录与访问控制怎么选？

详细比较

先判断要保护入口还是管理身份

几个自托管网页需要统一登录，并在反向代理前增加访问控制时，可以先评估 Authelia。若多个应用使用不同身份协议，还需要管理用户、应用接入和登录流程，可以先评估 authentik。这个分界是工作重心，不是绝对功能边界：Authelia 也支持 OIDC，authentik 也能做代理前认证。选型前列出应用数量、接入协议、用户来源以及谁负责日常变更。只需要几个固定入口的人，未必受益于复杂流程；正在扩展应用和团队的人，也不应只看第一份配置有多少行。

依据：官方资料；选择条件为编辑分析。

当前版本与公开功能范围

截至二〇二六年十月十一日，官方最新发布标记为 Authelia 4.39.28 与 authentik 2026.8.3。本文依据当前官方文档比较代理认证、身份协议、用户与流程维护，不把路线图当作已经可用的能力。authentik 另有 Enterprise 功能和支持，采用前应核对目标功能是否需要许可证。发布号较新不能直接证明产品更安全，也不能替代目标应用的兼容验证。已有系统升级应阅读对应版本说明，检查配置变化和回退条件，而不是直接追逐一个最新标签。

依据：官方资料、官方资料、官方资料；选择条件为编辑分析。

代理认证怎样接入现有应用

Authelia 提供反向代理集成说明，让代理在放行请求前取得认证与授权结果。authentik 的 Forward auth 同样使用既有反向代理处理应用流量，由 Outpost 检查认证和授权。两种方式都适合没有合适原生身份接入的网页，但具体代理、域名和路径仍需按官方集成配置。编辑建议先测试完整访问路径，包括登录跳转、退出和访问被拒绝时的行为。看到登录页只是一个步骤，不等于应用的所有入口已经经过同样的检查。选择应看现有代理能否清楚维护这些规则。

依据：官方资料；选择条件为编辑分析。

原生OIDC与代理前登录要分开

如果应用原生支持 OIDC，应评估直接通过身份提供方完成登录：应用可以获取明确的身份信息，再结合自己的业务权限。Authelia 和 authentik 都有 OIDC 接入路径，不能把前者说成只会检查代理请求。authentik 的 Provider 文档还列出 SAML 等协议，适合协议需求较多的应用组合。代理前登录主要解决进入请求路径的问题，原生接入还涉及回调地址、客户端身份与声明映射。先按每个应用选择合适方式，比为了统一而把所有应用强行套进同一种登录模型更合理。

依据：官方资料、官方资料；选择条件为编辑分析。

用户来自文件还是管理流程

Authelia 的认证后端主要有文件与 LDAP 两种路径，文件中保存用户资料及密码哈希，LDAP 可接入已有目录。对少量固定用户，配置文件容易纳入既有维护流程；用户经常变化时，账户更新、群组变动和撤权需要明确责任。authentik 提供用户管理和来源模型，更适合围绕管理界面及流程组织身份。选型时应模拟新增成员、修改群组和停用成员，而不仅是创建一个测试账号。已有目录本身仍需维护，不能把接入 LDAP 理解为身份资料从此无需检查。

依据：官方资料、官方资料；选择条件为编辑分析。

流程灵活性会增加审查工作

authentik 用 Flow、Stage 与 Policy 组合认证、授权、注册和恢复等流程，可以使用默认流程，也可以定制。适合需要不同用户或应用采用不同验证步骤的团队；代价是维护者必须理解阶段顺序、绑定和策略生效条件。Authelia 的常见配置则围绕认证后端、会话和访问规则展开，对固定入口较容易形成统一规范。编辑建议先确定必须实现的流程，再判断是否值得承担定制复杂度。一个看起来功能丰富的登录流程，如果交接人员无法解释每一步为何出现，仍会成为运维负担。

依据：官方资料；选择条件为编辑分析。

访问控制不能取代业务授权

Authelia 可以按域名、资源和用户群组等条件表达访问规则；authentik 也通过应用、Provider 与策略组织访问。无论选择哪个，登录成功不等于用户应该获得应用内的管理权。账单、文件删除、团队资料和后台操作等业务权限，仍需由应用及接入方式正确落实。编辑建议分别写下入口允许访问的人员和应用内允许执行的动作，检查身份字段与群组映射是否一致。不要因为已经配置了统一登录，就把应用自己的角色检查关闭或忽略撤权后的实际效果。

依据：官方资料；选择条件为编辑分析。

Forward auth模式影响隔离粒度

authentik 官方区分单应用与域级 Forward auth。单应用模式便于让不同应用拥有各自 Provider、绑定和授权行为；域级模式减少逐应用设置，但不能用不同应用级策略分别限制用户。若同一父域下既有普通团队工具又有敏感管理页面，这个选择会直接影响权限设计。Authelia 也需要通过具体资源规则检查边界。选型时不要只看配置少了几个对象，而应验证普通用户确实无法进入管理应用。简单部署方式是否合适，取决于访问范围是否同样简单。

依据：官方资料；选择条件为编辑分析。

多因素与恢复路径需要一起试

两者提供多因素相关能力，Authelia 官方包括安全密钥与 Passkeys 文档；具体使用步骤与第一、第二因素角色应按当前配置核对。支持某种验证器并不自动证明丢失设备后仍有合适恢复流程。采用前应在隔离账号上测试新增验证器、正常登录、设备不可用和管理员恢复，确认普通用户不会被迫采用超出能力的步骤。不要把某种验证方式名称当作独立安全审计结果。更有用的比较是团队能否执行清楚的注册与恢复流程，并在撤销用户或设备后验证权限变化。

依据：官方资料；选择条件为编辑分析。

应用与Outpost的维护边界

authentik 的 Outpost 负责部分 Provider 的运行与接入，不是每个原生 OIDC 应用都需要一个独立代理容器。部署时应理解实际采用的 Outpost 类型、位置、版本与访问范围，再决定由谁更新和排障。Authelia 的代理集成同样有两端配置需要协调。编辑建议画出浏览器、代理、认证服务和应用的请求路径，注明哪一步使用哪种凭据或身份信息。身份服务正常但接入组件异常，用户仍可能无法登录；因此不能只检查中心登录页面就宣布所有应用接入成功。

依据：官方资料；选择条件为编辑分析。

资源与免费功能怎样计算成本

authentik 的当前 Docker Compose 文档对测试及小规模生产给出至少两核 CPU、两 GB 内存的主机要求，实际余量还要考虑数据库与工作负载。Authelia 也需要保存认证相关状态，不能把一个配置文件当成全部运行依赖。两者都要计算主机、备份、邮件、升级和维护时间；authentik Enterprise 的授权与支持另行核对。本文没有给出未经当前验证的订阅报价，也没有做同机资源测试。选择时应比较完整运行责任，避免用免费软件标签推出总体费用为零。

依据：官方资料；选择条件为编辑分析。

集中登录让故障范围变大

多个应用依赖同一身份服务后，身份服务、目录或接入组件故障可能同时影响多个应用登录。编辑建议先明确故障时哪些访问应该拒绝、谁能恢复以及怎样保留经过控制的应急管理路径。备份应覆盖实际使用的配置、数据库、密钥和相关恢复资料，并验证在隔离环境恢复后还能正确登录。Authelia 的存储与加密配置、authentik 的版本升级和持久化状态都需要维护。这里不主张自动放开认证来换取可用性，而是把可恢复性和变更责任作为选择条件。

依据：官方资料；选择条件为编辑分析。

用新增与撤权场景完成试选

准备一个可用原生 OIDC 的测试应用和一个代理前认证的测试网页，验证普通用户登录、管理员登录、无权用户被拒绝，以及用户停用后的实际行为。再检查退出、会话变化、移动浏览器和一次隔离升级。固定少量入口、已有文件或 LDAP 管理流程，可优先试 Authelia；多协议应用、频繁用户变化和定制流程，可优先试 authentik。测试应记录真实结果，不能用示例截图替代证据。已有方案能清楚满足接入与恢复需求时，继续使用它也是合理选择，没有必要强行迁移。

依据：官方资料；选择条件为编辑分析。