后端热榜里不只有队列和 Agent 沙箱。今天 goauthentik/authentik 再次出现在 GitHub Trending：开源 IdP，星标已过 2.3 万，支持 OIDC/OAuth2、SAML、LDAP、RADIUS，并带 Proxy / Forward Auth 去兜那些“自己不会登录”的老应用。
自建身份层这件事，2026 年反而更急。内部工具、AI agent 控制面、临时 demo 环境，默认暴露在同一套入口后面。你可以用云厂商 IAM，也可以把 SSO 收敛到自己能审计的栈上。authentik 走的是后者。
它解决什么，不解决什么
authentik 是 Identity Provider + 应用接入层，不是业务用户表的替代品。适合：
- 给一堆内部服务统一登录（Grafana、Admin、自研后台）
- 为不支持 OIDC 的遗留系统加登录墙（Proxy / Forward Auth）
- 自托管，数据不出自己的 VPC / 机房
不适合：把它当唯一业务账号系统硬焊进所有表结构，却不做应用侧授权模型。IdP 管“你是谁、能否进这扇门”；对象级权限仍要业务自己做。
部署路径官方写得很清楚：小规模 Docker Compose，大规模 Helm。企业版对标的是替换 Okta / Entra 一类，社区版对 homelab 到中型集群都够用。
Forward Auth：后端最该懂的接入方式
很多服务已经有 Nginx / Traefik / Caddy，不想让 IdP 反代全部流量。authentik 的 Forward Auth 就是为这个场景准备的：
- 反代照常把业务流量打到 upstream
- 每次请求先
auth_request（或等价机制）问 outpost：“这个人过没过？” - 401 时跳去登录；通过则把用户名、组、邮箱等头转给上游
单应用模式下，外部域名上的 /outpost.goauthentik.io 指到 outpost，其余路径仍是你的应用。文档见 Forward auth 与 Proxy provider。
Nginx 侧骨架长这样（生产请按官方最新文档改 host 与 cookie 处理）：
location / {
auth_request /outpost.goauthentik.io/auth/nginx;
error_page 401 = @goauthentik_proxy_signin;
auth_request_set $authentik_username $upstream_http_x_authentik_username;
proxy_set_header X-authentik-username $authentik_username;
proxy_pass http://app:8080;
}
location /outpost.goauthentik.io {
proxy_pass http://outpost:9000/outpost.goauthentik.io;
proxy_set_header Host $host;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
}
上游服务要做的事很无聊，但必须做：信任这些头之前，确认请求只来自反代网段。若应用端口对公网直开，伪造 X-authentik-username 就是开门钥匙。
和 Agent / 内部平台一起出现时
Agent 控制台、MCP gateway、临时评测环境，正在变成新的“内部应用集群”。它们往往：
- 迭代快，顾不上每套都接一遍完整用户体系
- 权限一旦漏，影响面是数据和工具调用，不只是一个页面
比较稳的折中：
- 边缘统一认证：所有内部 hostname 进同一 IdP（authentik 或你们已有的）
- 应用内细粒度授权：用组/角色映射到 agent 可调用的工具集
- 服务账号与人类账号分开：cron、agent worker 走 client credentials 或 mTLS，不要共用员工 SSO cookie
- 会话与退出：Forward Auth 的 cookie 作用域、登出传播要在上线前测一遍；否则“以为退出了，侧门还开着”
如果你已经在边缘用 Cloudflare Access 之类，authentik 更适合 需要 LDAP/SAML 兼容、或必须自托管审计日志 的环境。两者可以分层，不必二选一原教旨。
上线清单（后端视角）
- Outpost 与 core 的版本一起升；RC（如 2026.8.0-rc 系列）别直接上生产
- 备份 Postgres；IdP 挂了等于全站登录挂了，要有恢复演练
- 限制 admin 接口与 outpost 管理面的网络暴露
- 给每个应用单独 Provider，避免一个 client 打天下导致权限难收
- 监控登录失败率、outpost 延迟；认证变慢时用户会觉得“整个后端挂了”
组映射建议一开始就设计成“可丢弃的粗粒度”，例如 eng、ops、readonly，再在应用里映射到具体权限。别在 IdP 里建几十个与业务功能一一对应的组，半年后没人敢删。应用侧保留能力开关；IdP 只回答身份和少数稳定角色。
日志方面，至少留下：谁在何时登录失败、哪个 Provider、来源 IP、是否触发暴力破解防护。这些日志最后会变成安全事件的时间线。若合规要求保留期长，别只靠容器本地盘。
小结
authentik 再次冲榜，说明身份层仍是后端基本功。Proxy / Forward Auth 让老应用和新的 agent 控制面能共用同一套门禁，而不必先重写登录。真正要守住的是：头不可信除非网络拓扑保证、人类会话与机器凭证分离、IdP 本身的高可用和备份。
先选一个内部工具做 Forward Auth 试点，跑通登入登出和组映射，再铺到 agent 平台。比一上来“全公司迁 IdP”现实得多。
图：反代将认证检查交给 outpost，业务流量仍直达应用
