Dex：不做用户库，只做”联邦 OIDC 翻译层”的身份服务

在多服务、多团队的平台里，“登录”这件事最容易失控：有的应用要接 LDAP，有的要接 GitHub 组织，有的要接公司 SAML，每个应用都自己写一遍对接，维护噩梦由此开始。Dex 给出的答案是一个”联邦 OpenID Connect 提供方”：它坐在所有应用前面，自己不拥有用户数据，而是把上游各种身份源（LDAP、SAML、GitHub、Google、Microsoft……）统一翻译成标准 OIDC。你的应用从此只跟 OIDC 打交道。本文基于 Dex 官方网站与 GitHub README，拆解它的定位、机制与边界。

一、出发点：让所有应用只讲一种协议

Dex 是一个用 Go 写的身份服务，用 OpenID Connect（OIDC）为其他应用驱动认证。它通过 connector（连接器） 把认证委托给上游：LDAP 服务器、SAML 提供方，或 GitHub、Google、Active Directory 这类既有 IdP。客户端只写一次对接 Dex 的逻辑，Dex 替你处理五花八门的后端协议。

它的核心产物是 ID Token——一个由 Dex 签名的 JWT，附带标准声明（iss、sub、aud、exp、iat、email、groups、name 等），证明”是谁、什么时候登录、属于哪个客户端”。因为这些 token 由 Dex 签名且声明标准化，其他系统可以把它们当作服务间凭证直接消费——官方点名 Kubernetes 和 AWS STS 已经能直接消费 Dex 签发的 ID Token。

二、架构：翻译层，不是数据面

官方文档把架构画得很清楚（见上图）：左边是用户认证（USER AUTHN）与机器认证（MACHINE AUTHN），通过 OIDC 打到中间的 Dex；Dex 一边挂 Connectors（OpenID、LDAP、Local、Mock、GitHub、GitLab、Bitbucket 以及更多），另一边挂可插拔的 Storage（PostgreSQL、MySQL、SQLite、etcd、Kubernetes CRD、内存）。

理解 Dex 的关键是它主动不做什么：

• 它不拥有用户状态。官网在对比 Zitadel、Authentik 时点得很透：Zitadel 是事件溯源的 IAM 平台，自己在 CockroachDB 上管用户、组织、项目和审计日志；Authentik 是 Python/Django 写的、有自己用户库和流程引擎的平台。而 Dex 没有用户库——它只是把你已经在用的上游身份源”翻译”成标准 OIDC 声明；
• 它是协议提供方，不是网关。Authelia / OAuth2 Proxy 坐在 HTTP 层、用 ForwardAuth 头保护上游路由，是反向代理的伴侣；Dex 是一个完整的 OIDC issuer，任何标准客户端都能直接对它跑授权码流；
• 它不带 JVM、不强制数据库。对比 Keycloak（重型 Java 应用、需要后台数据库），Dex 是单个静态 Go 二进制，存储可插拔甚至可选；
• 它自带登录页和连接器。对比 Ory Hydra（headless OAuth2 服务器，登录页要你自己写），Dex 把登录 UI 和上游连接器塞进同一个进程。

三、连接器矩阵：能力并不对齐

Dex 支持的连接器很多，但官方诚实地用一张表标注了每个连接器的能力差异——refresh token、groups 声明、preferred_username 声明，以及成熟度（stable/beta/alpha）。几个要点：

这里有两个必须点出的现实：

1. 协议本身会限制能力：SAML 没有非交互式刷新断言的方式，所以走 SAML 连接器登录的用户拿不到 refresh token——而 kubectl 这类需要离线访问的客户端恰恰要 refresh token。选连接器时不能只看”能不能登录”；
2. SAML 连接器的官方警告：README 直接在表里标注它”Unmaintained and likely vulnerable to auth bypasses”。这对一个身份组件来说是相当严重的信号，生产上若依赖 SAML 必须自行评估。

四、典型落地：Kubernetes SSO

Dex 与 Kubernetes 的结合是它最经典的用法：Dex 可以用 Custom Resource Definition 原生跑在 K8s 集群上，并通过 API server 的 OIDC 插件驱动集群认证。kubelogin、kubectl 这类客户端可以代表用户登录——用户用任何 Dex 支持的 IdP 登录，再拿到访问集群的凭证。官方文档还有”kubelogin 对接 Active Directory”等指南。

此外它还有几个轻量场景：作为依赖打包进你的应用（瞬间支持几十个 IdP）、统一平台认证（加 IdP 时不用改应用代码）、以及内置 mock 连接器让本地开发不用 provision 真实身份。

五、客观优势与局限

优势：

1. 协议收敛做得干净：所有应用只说 OIDC，上游换成 LDAP/SAML/GitHub 都不用改应用、不用重新部署、不用重写认证代码；
2. 极轻量：单 Go 二进制、官方 Helm chart、存储可插拔，没有 JVM 也不强制数据库；
3. K8s 原生：CRD + API server OIDC 插件 + kubelogin，是集群 SSO 的成熟路径；
4. 中立、可自托管：CNCF 沙箱、Apache-2.0，不像 Cognito/GCP Identity 那样把认证路径绑死在某朵云的 API、账单和故障面上。

局限与官方口径：

1. 它不是 IAM 套件：不管用户生命周期、不管组织/项目/审计日志，要这些得找 Zitadel/Authentik/Keycloak；
2. 连接器能力不齐：refresh token、groups、preferred_username 各有缺口，SAML 连接器甚至被官方标注无人维护、有认证绕过风险；
3. 不适合当反向代理网关：它不做 ForwardAuth 头注入，不想在 HTTP 层保护路由的人应选 Authelia/OAuth2 Proxy；
4. 存储虽可插拔但要自己管：in-memory 重启即失，生产上仍需 Postgres/etcd/K8s CRD 等后端；
5. alpha/beta 连接器未完全冻结：Google、OAuth2、Bitbucket、OpenStack 等仍在 alpha，API 可能变。

六、适合谁用

• Kubernetes 集群要统一 SSO：把 GitHub/OIDC/LDAP 登录接到 kubectl 和 dashboard；
• 多个内部应用已经（或计划）说 OIDC，但上游身份源五花八门：用 Dex 当一层翻译，避免每个应用各接一遍；
• 想自托管、不想被云厂商 IAM 绑定，又嫌 Keycloak 太重的团队；
• 要给自有产品加”支持几十个登录源”能力的平台团队：把 Dex 当依赖打包。

反过来，如果你需要一个自带用户库、组织模型、审计日志和管理后台的完整 IAM，Dex 官方自己建议你去看 Zitadel、Authentik 或 Keycloak。

参考来源

• Dex 官方网站：Federated OpenID Connect
• Dex 官方 GitHub 仓库（连接器能力表）
• Koala 聊开源 科技周报：Dex｜联邦 OIDC 身份认证