在上一篇 开篇 中，我们探讨了统一登录能为一家 500 人公司带来的结构性改变，以及为什么在一众产品中最终敲定了 authentik。它不仅能做 OIDC、SAML 单点登录，还能对外直接提供 LDAP 和 RADIUS 服务，甚至能为没有登录功能的页面套上一层代理认证的“防盗门”。
但这四种接入方式的底层原理千差万别，选错了，要么员工体验极差，要么就会在隐秘的角落留下安全漏洞。
本篇将深入实战，从整体架构设计和核心概念出发，聊聊这四种接入方式在遇到具体业务系统时应该怎么选，以及离职禁用策略在不同协议下何时才会真正生效。
如果你想直接看某一种协议的配置实战和时序图，可以跳转到对应的详解篇：
- OIDC：授权码流程、令牌与配置要点
- 代理认证：用 Forward auth 给 Prometheus 加一道门
- LDAP：虚拟目录、bind 流程与 JumpServer 接入
- RADIUS：VPN 与网络设备接入
内容基于 authentik 2026.8 的官方文档。
TL;DR
- 一个身份中心，四种接入方式：OIDC 给现代 Web 应用，代理认证给没有登录功能的页面，LDAP 给只认 LDAP 的老系统，RADIUS 给 VPN 和网络设备。四种方式验证身份时走的都是 authentik 的同一套流程（flow）和绑定（binding），所以账号、禁用状态、权限只有一份。
- 能用 OIDC 就别用 LDAP：OIDC 下应用拿不到员工密码，能扫码、能加二次 MFA；LDAP 和 RADIUS 下密码会经过应用或设备，员工还得单独设一个密码。
- 应用没有任何绑定时，所有人都能访问：每接入一个应用都要检查绑定。
- authentik 是全公司的登录入口：多副本、数据库主备、不依赖它的应急账号是上线前提。
- 禁用账号只拦得住新登录：已经登录的应用会话、已经建立的 VPN 连接，要靠缩短会话有效期、back-channel logout 或手动踢下线。
Table of contents
Open Table of contents
1. 整体架构
在这家公司的设计里，飞书是人员信息的唯一来源，authentik 是唯一的身份中心：
- 员工用飞书扫码登录 authentik（authentik 作为 OIDC 客户端接入飞书）。
- 一个同步脚本定时把飞书通讯录同步到 authentik：入职自动建号，部门变成用户组，离职或冻结自动禁用。
- 各业务系统按自己支持的协议接入 authentik。
飞书管“人是谁”，authentik 管“能进哪里”，各系统只认 authentik。
这个架构有一个必须正视的代价：authentik 成为了全公司所有系统的登录命脉。一旦它发生大面积故障，所有人都将无法登录任何系统，这甚至包括急需连上去排障的运维人员本身（因为 VPN 和 JumpServer 也挂在它上面）。
因此，多副本横向扩展、高可用数据库主备，以及必须预留一条不依赖 authentik 的本地应急通道，是这套架构上线的硬前提。高可用相关的具体思路可以参考 高可用系统设计 和 冗余与容灾。
2. 几个基本概念
authentik 后台里和接入有关的对象：
| 概念 | 含义 | 举例 |
|---|---|---|
| Application（应用） | 一个要接入的系统，员工在应用门户里看到的就是它 | GitLab |
| Provider | 应用用什么协议和 authentik 对接，每个应用对应一个 | GitLab 用 OAuth2/OpenID Provider |
| Outpost | 独立运行的协议组件，替 authentik 对外提供 LDAP、RADIUS、代理认证 | LDAP outpost |
| Flow（流程） | 登录时要走的步骤：识别用户、校验密码、校验 MFA 等 | default-authentication-flow |
| Binding（绑定） | 决定谁能访问某个应用，或某个流程步骤对谁生效 | GitLab 绑定 飞书/技术中心 组 |
| Source | 外部身份来源，authentik 作为客户端去接入它 | 飞书 |
四种接入方式在底层究竟由谁来提供服务：
| 接入方式 | 对应的 Provider | 实际承载服务的组件 | 监听端口 |
|---|---|---|---|
| OIDC | OAuth2/OpenID Provider | authentik-server Pod 本身 | HTTPS 443 |
| 代理认证 | Proxy Provider | 内置 Outpost（跑在 server 进程里） | HTTPS 443（经过 Nginx） |
| LDAP | LDAP Provider | ak-outpost-ldap（独立的 Outpost Pod） | LDAPS 636 |
| RADIUS | RADIUS Provider | ak-outpost-radius（独立的 Outpost Pod） | UDP 1812 |
这里有一条最容易踩坑的铁律需要牢记：如果一个应用没有配置任何绑定（Binding），那么所有人都能访问它。 每次接入新应用时，务必反复检查绑定关系。
3. 四种接入方式一览
OIDC：员工跳转到 authentik 登录（飞书扫码），authentik 给应用签发 ID token。授权码经过浏览器，令牌在服务器之间直连交换，应用始终拿不到员工密码。最常见的坑是 Provider 不选签名密钥、Redirect URIs 留空、上线后修改 Subject mode。
代理认证：Nginx 用 auth_request 问 authentik 的 Outpost 放不放行，没登录就跳去登录。适合 Prometheus、Alertmanager 这类没有登录功能的系统。它只管“能不能进”，前提是后端只能经由 Nginx 访问。
LDAP：authentik 提供一个只读的虚拟目录，bind 就是在 authentik 里执行一次 bind flow。员工在应用登录框输入 authentik 密码，密码会经过应用。Bind mode 一定选 Direct，Cached bind 下禁用的账号在缓存过期前仍能登录。
RADIUS：VPN 网关和网络设备把员工的用户名密码转给 RADIUS Outpost。authentik 只存不可逆的密码哈希，所以密码认证只支持 PAP；动态码要拼在密码后面输入。
4. 接入协议怎么选
| 方式 | 员工怎么登录 | 应用能否拿到员工密码 | 能否飞书扫码 | 二次 MFA | 典型系统 |
|---|---|---|---|---|---|
| OIDC | 跳转到 authentik 登录 | 不能 | 能 | 能，扫码后再验一次 | GitLab、Jenkins、Harbor、Grafana、Argo CD |
| 代理认证 | 跳转到 authentik 登录 | 不能 | 能 | 能 | Prometheus、Alertmanager |
| LDAP | 在应用的登录框输入用户名和 authentik 密码 | 能，收到明文密码 | 不能 | 只能把动态码拼在密码后面 | JumpServer、老系统 |
| RADIUS | 在 VPN 客户端或设备上输入 | 设备能拿到 | 不能 | 只能把动态码拼在密码后面 | VPN、交换机、无线 |
接入一个新系统时，请严格按照以下优先级来选，能用前面的就绝对不用后面的：
- OIDC：系统支持 OIDC 或 OAuth2 登录。现在绝大多数现代系统都支持。
- SAML：系统只支持 SAML，常见于商业 SaaS。原理和 OIDC 类似，消息格式是 XML。
- 代理认证：系统没有自己的登录功能，或登录功能没法对接外部身份。
- LDAP：系统只支持 LDAP，或需要 LDAP 查询用户和组。
- RADIUS：VPN 和网络设备，且不支持 SAML 或 OIDC。
越往后，员工体验越差（要单独设密码、不能扫码），应用能接触到的凭据也越多，安全风险越高。
5. 离职禁用后多久真正失效
四种方式都会拒绝已禁用账号的新登录，但对于已经建立的会话，处理方式各不相同：
| 方式 | 新登录 | 已经登录的会话 |
|---|---|---|
| OIDC | 立即拒绝 | 应用的会话继续有效，直到过期。应用支持 back-channel logout 时，authentik 会通知它结束会话 |
| 代理认证 | 立即拒绝 | Outpost 的会话在过期前可能仍有效。紧急时在 authentik 里清除该用户的会话，并确认已失效 |
| LDAP | Direct bind 下立即拒绝；Cached bind 下要等缓存过期 | 应用（如 JumpServer）的会话继续有效，要在应用里手动断开 |
| RADIUS | 立即拒绝 | 已建立的 VPN 连接一般保持到断开，要在 VPN 设备上手动踢下线 |
所以，“统一身份平台一键禁用”只解决了一半问题。另一半要靠这些措施来兜底：
- JumpServer、GitLab 这类高危系统，尽量缩短会话有效期。
- 支持 back-channel logout 的应用，务必把它打开。
- 紧急离职（比如安全事件）时，在 authentik 禁用账号后，必须立刻到 JumpServer、VPN 上确认会话已断开。
- 员工在各系统里自己生成的个人 token（GitLab Personal Access Token、Harbor 机器人账号等）不受 authentik 控制，要在对应系统里单独吊销。
6. 生产取舍与踩坑经验
飞书账号的安全就是整个平台的安全。 员工扫码后能进入所有接入的系统，飞书账号被盗等于全线失守。飞书侧要对全员开启登录二次验证，飞书管理员要少而可审计（他们能改员工邮箱，间接决定 authentik 里的用户名）；高危应用在扫码之后再加一道 authentik 自己的 MFA。
用户名关联要防冒用。 让同步脚本建的账号和扫码登录对上号，最简单的办法是“按用户名关联”（邮箱前缀）。隐患是：如果某个飞书账号的邮箱前缀恰好是 akadmin 或某个服务账号的名字，扫码就能登进那个手工账号。在飞书登录流程里加一个拒绝步骤，只允许带同步标记的账号通过；手工账号的用户名也不要用可能和员工重名的名字。
最容易出事故的是存量账号迁移，而不是协议本身。 GitLab、Jenkins 里早有本地账号。接入单点登录后，如果系统认为新身份和老账号不是同一个人，就会新建一个重复账号，员工的项目、权限、历史记录都留在旧账号下。每接一个系统前，先导出账号和 authentik 比对，查清它按 sub、用户名还是邮箱关联，再找几个真实员工试登录。
认证层和网关、网格是互补关系。 authentik 解决的是“人”登录系统；服务之间的调用鉴权，交给 API 网关 的令牌校验或 Service Mesh 的 mTLS。不要试图让每个内部服务都去走一遍员工的登录流程。
7. 参考资料
- authentik 文档：Applications、Providers、Outposts、Flows
- authentik 集成文档目录：GitLab、Grafana 等常见系统的接入配置
- 本系列：开篇 · OIDC · 代理认证 · LDAP · RADIUS