Authelia：给一堆自建服务加一道统一登录
要解决的问题很具体：在反向代理层拦一道门，没登录的人根本到不了后端服务。这样即使某个应用本身有漏洞，攻击面也被缩小到「门卫」这一层。
一、它的工作原理
用户 → 反向代理 → Authelia（校验会话）→ 通过 → 后端服务
↓ 未通过
登录页 / 双因素它不做业务，只做认证：账号存在自己的配置文件或数据库里，登录后签发一个域级 Cookie，同一域名下的所有子服务共享这个会话。
二、两种拦截策略，别搞混
| 策略 | 行为 | 适合 |
|---|---|---|
| forward-auth | 未登录直接拒绝（401/302 到登录页） | 纯网页服务 |
| auth-request | 询问是否已登录，自行决定放不放行 | 需要部分公开的服务 |
区别在「部分公开」：比如一个博客要允许访客看，但 /admin 要登录，就得用第二种，让应用自己判断路径。
三、最小配置
services:
authelia:
image: authelia/authelia:latest
restart: unless-stopped
volumes: ["./config:/config"]
ports: ["9091:9091"]
# Caddy 侧对接示例
example.com {
forward_auth authelia:9091 {
uri /api/verify?rd=https://auth.example.com/
copy_headers Remote-User Remote-Groups Remote-Email
}
reverse_proxy backend:8080
}copy_headers 那一行很关键：把认证通过的用户名传给后端，后端就能知道「是谁在访问」，不用自己再做一次登录。
四、双因素怎么开才不折腾
TOTP（手机上的验证码 App）是最省事的方案：不需要短信通道，不依赖第三方，离线也能用。
但要有备用方案：手机丢了怎么办。正确做法是注册时把恢复码打印出来放抽屉，或者配两个设备同时绑定。否则某天手机一换，所有自建服务都进不去。
五、常见的三个坑
- Cookie 域设错：会话只对
auth.example.com有效，其他子域每次都要重新登录。要把 Cookie 域设成父域； - 时间不同步：TOTP 依赖时间，服务器时间漂移超过 30 秒就验证失败。装个时间同步服务；
- 把自己锁在外面：配错规则后连管理页都进不去。做法是先在一台上配好并测试，再批量套用到其他服务。
六、替代方案：Authentik
如果需求不止「拦一道门」，还包括用户自助注册、OAuth/OIDC 对接、按组授权，那就该看 Authentik。它功能更全，代价是部署更复杂（多个容器 + 数据库 + Redis）。
判断标准很简单：只需要「登录后才能访问」→ Authelia；需要「身份提供商」→ Authentik。
七、别把所有服务都加进来
有些服务本身已经有成熟的账号体系（比如代码托管、网盘），再套一层会让日常使用变累。合理的分界是：
- 加一层：只读型工具、内部面板、监控页、下载器；
- 不加：本身有完善权限模型、需要 API 直连的服务。
反向代理的配置见 Caddy；自建服务的取舍见 自建 vs SaaS。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论