认证的胶水：authentik 为什么在 AI 时代重新火起来
认证的胶水：authentik 为什么在 AI 时代重新火起来
每个 AI 应用都要面对同一个问题：API key 怎么管？
你给团队 10 个人每人一个 OpenAI key，有人离职了你回收 key，有人需要不同权限，你要做 key 分级。你接入了 5 个 AI 服务（OpenAI、Anthropic、DeepSeek、通义、智谱），每个服务一套认证逻辑。你还要对接内部的 20 个工具，每个工具都要知道"当前用户是谁、能做什么"。
这些需求拼在一起，就是身份提供商（IdP）要解决的问题。
goauthentik/authentik 是一个开源的 IdP，支持 SAML、OAuth2/OIDC、LDAP、RADIUS、SCIM 全套协议，可以自托管在你的服务器上。它不是新项目——从 2020 年就开源了——但最近在 GitHub Trending 上重新火起来，背后有结构性的原因。
问题：AI 时代的身份碎片化
AI 应用爆发之前，身份管理的场景相对简单：员工登录企业内网、SaaS 应用 SSO、API 访问控制。Okta、Auth0、Entra ID 这些方案够用了。
AI 应用爆发之后，身份管理的复杂度上了一个台阶：
第一，服务到服务的认证激增。 一个 AI Agent 可能要调用 5 个外部 API，每个 API 都要认证。传统方案是给每个服务一个长期 key，但长期 key 泄露的风险高，轮换成本大。
第二，多租户 AI 应用的权限细分。 你做了一个 AI 编程助手，不同团队能用不同模型（A 团队用 GPT-4，B 团队用 DeepSeek），不同人有不同额度。这些策略要集中管理，不能散落在各处。
第三，合规要求升级。 GDPR、SOC 2、等保 2.0 都要求"谁在什么时候访问了什么数据"的完整审计日志。散落的 API key 方案无法满足。
这三个趋势叠加，让"自托管 IdP"从可选项变成了必选项。
authentik 的定位：认证的胶水
authentik 把自己定位为"authentication glue you need"——你需要的认证胶水。这个"胶水"比喻很精确：
胶水不是建材，是连接件。 authentik 不替代你的应用，不替代你的模型，不替代你的数据库。它做的事是把"你是谁"这个信息从一处传递到另一处——从企业 AD 到 AI 应用，从 Google Workspace 到内部工具，从 SAML IdP 到 OAuth2 客户端。
胶水要适配多种材质。 authentik 支持的协议列表说明它的适配范围：
| 协议 | 典型场景 |
|---|---|
| SAML 2.0 | 企业 SSO、传统应用 |
| OAuth 2.0 / OIDC | 现代 Web 应用、API 认证 |
| LDAP | 基础设施组件（Jenkins、Grafana） |
| RADIUS | 网络设备、VPN |
| SCIM | 用户生命周期自动化 |
胶水的价值在于省去 N×M 的集成。 没有 authentik，你有 N 个应用和 M 种协议，要做 N×M 次集成。有了 authentik，你做 N+M 次集成——每个应用接 authentik，每种协议接 authentik。这就是胶水的数学。
为什么自托管
Okta、Auth0、Entra ID 都是云托管的 IdP，为什么要自托管？
第一，数据主权。 身份数据是最敏感的数据之一。云 IdP 意味着你的用户目录、访问策略、审计日志都在第三方手里。对于金融、医疗、政府场景，这不可接受。
第二，成本可控。 云 IdP 按月活收费，一个 1000 人的团队用 Okta 一年可能花 5-10 万美元。authentik 自托管在一台 50 美元/月的 VPS 上就能跑。
第三，定制能力。 authentik 用 Python 写策略，你可以用代码定义任意复杂的认证流程。云 IdP 的策略引擎是有限的 DSL，遇到特殊需求就要绕路。
第四，AI 时代的特殊需求。 AI 应用经常需要"服务到服务"的短期 token，这种 token 的签发和撤销频率远高于人类登录。自托管 IdP 可以承受高频 token 操作，云 IdP 通常按 API 调用收费，高频场景成本爆炸。
技术架构：Python + Go + PostgreSQL
authentik 的技术栈有意思：
- 核心服务：Python（Django）
- 前端：TypeScript + Web Components
- 数据库：PostgreSQL
- 消息队列：Redis
- 部署：Docker Compose / Kubernetes
和 Keycloak 的对比
authentik 不是唯一的开源 IdP。最知名的竞品是 Keycloak（Red Hat 维护）。
| 维度 | authentik | Keycloak |
|---|---|---|
| 语言 | Python | Java |
| 部署复杂度 | 低（Docker Compose 一键起） | 中（JVM 调优） |
| 策略可编程性 | Python 代码 | JS Policy |
| UI 现代化程度 | 高（Web Components） | 中（传统 JSP） |
| 社区规模 | 较小但活跃 | 大且成熟 |
| 企业支持 | 商业版 | Red Hat 支持 |
谁该用
- AI 应用团队：需要给客户做 SSO、需要管理多个 AI 服务的 API key、需要审计日志
- 自托管爱好者：已经自托管了 Nextcloud、Gitea、Jellyfin，缺一个 IdP 把它们串起来
- 企业 IT：需要替代 Okta 的自托管方案，预算敏感
- 合规场景：需要完整审计日志和数据主权
局限
- 社区比 Keycloak 小：遇到冷门问题，Stack Overflow 上答案少
- 企业功能在付费版：某些高级功能（如多租户隔离）需要商业版
- Python 性能瓶颈：高并发场景需要做好缓存和水平扩展
- 学习曲线：虽然比 Keycloak 简单，但 IdP 概念本身有门槛（SAML 的元数据交换、OIDC 的 PKCE 流程等）
结尾
authentik 在 2026 年重新火起来不是偶然。AI 应用爆发带来了身份管理需求的指数级增长——更多的服务要认证、更细的权限要管理、更严的合规要满足。云 IdP 的成本和灵活性在这个背景下变成了瓶颈。
authentik 的"胶水"定位很精准：它不试图替代你的应用或模型，只做"你是谁"这个信息的传递。一个支持所有协议、可自托管、可编程策略的 IdP，在 AI 时代是基础设施级别的东西。
胶水的价值不在自身，在于它让多少块建材能协同工作。
---
GitHub: https://github.com/goauthentik/authentik 官网: https://goauthentik.io 文档: https://docs.goauthentik.io