先分清它们解决的是不是同一个问题
两个项目都能给反向代理后面的服务加一道登录，但定位差得很远。
Authelia（4.39.28，29,384 star，Apache-2.0）是一个轻量的认证门户：单二进制、配置文件驱动、支持 TOTP/WebAuthn 两步验证，通过 forward-auth 把认证结果以请求头的形式交给上游。它不自带用户数据库，用户来自文件或 LDAP。
Authentik（2026.8.5，26,060 star）是一个完整的身份提供者：OIDC、SAML、LDAP、SCIM、应用目录、策略引擎，还带 outpost 做代理。它需要 Postgres 和 Redis，组件多，能力也全。
资源账先摆出来
| Authelia | Authentik | |
|---|---|---|
| 依赖 | 无（文件/LDAP） | Postgres + Redis |
| 常驻内存 | 约 100MB 量级 | 1GB 起，组件多时更高 |
| 配置方式 | YAML | Web 管理界面 |
| 协议支持 | forward-auth 为主 | OIDC/SAML/LDAP/SCIM |
Authelia 的接法
Nginx 里用 auth_request 把每个请求先问一遍 Authelia，返回 2xx 就放行，并把用户名写进请求头：
location / {
auth_request /authelia;
auth_request_set $user $upstream_http_remote_user;
proxy_set_header Remote-User $user;
proxy_pass http://app:8080;
}Caddy 用 forward_auth 指令，思路一样。要点是：认证服务和业务服务必须在同一个「信任边界」内，上游不能直接暴露，否则绕过代理就能跳过登录。
Authentik 适合什么
当你需要「一套账号登录所有应用」时，Authelia 就不够了。Authentik 能做 OIDC Provider，让 GitLab、Grafana、Nextcloud 走标准 SSO；能同步 LDAP 目录；能按组做访问策略。
代价是运维复杂度：数据库备份、版本升级、outpost 的部署，都要单独考虑。它更像一个产品，而不是一个中间件。
怎么选
| 你的情况 | 建议 |
|---|---|
| 只想给几个自建服务加登录 | Authelia |
| 需要 OIDC/SAML 对接现成应用 | Authentik |
| 机器只有 2GB 内存 | Authelia |
| 要给团队做统一身份与权限 | Authentik |
两个共同的安全要点
第一，别把上游服务直接暴露。认证层只有在「所有流量都必须经过它」时才有意义。第二，会话 Cookie 的作用域要收窄，按域名设置，不要一个 Cookie 通吃所有子域。
我的判断
这两个项目的选择标准，不是「谁功能多」，而是「你有多少个应用需要统一身份」。一个、两个服务，Authelia 十分钟能配好；十个应用、还要对接现成的 OIDC 客户端，Authentik 的复杂度是值得付的。
最怕的是反过来：为了两个服务上 Authentik，最后花在维护数据库和升级上的时间，比服务本身还多。
暂无评论内容