Dex

What it is

Dex is an OpenID Connect (OIDC) identity provider that acts as a federation layer, not an identity store. It sits in front of upstream identity backends — LDAP, SAML, GitHub, GitLab, Google, Microsoft, LinkedIn, static config, or another OIDC provider — and exposes a single, consistent OIDC/OAuth2 interface downstream. Applications and infrastructure (Kubernetes API server, Argo CD, Gitea, internal tooling) talk to Dex once; Dex handles translating that to whatever auth backend an org actually runs. Originally built by CoreOS, now a CNCF Sandbox project.

Who builds it and why

303 contributors, active commit history through mid-2026, Apache-2.0 licensed. This isn't a single-vendor side project — it's a broadly used piece of plumbing that Kubernetes-adjacent tooling depends on. Companies that need OIDC-shaped auth in front of legacy or heterogeneous identity systems (mixed LDAP + SSO + social login environments) contribute because Dex solves a real gap: kube-apiserver and most cloud-native tools speak OIDC, but most enterprises don't have a clean OIDC backend to point at. Dex is the adapter.

Production readiness signal

• 10,930 GitHub stars, 303 contributors — healthy, not niche.
• Active as of the latest commit (2026-07-01) — maintained, not abandoned.
• Latest release v2.45.1 — mature version numbering, long track record of incremental releases.
• CNCF Sandbox maturity — this is the honest caveat. Despite wide production usage (it's been running in production at real companies for years, including as the reference OIDC provider for Kubernetes auth docs), it has not moved to Incubating or Graduated. Sandbox status reflects governance/process maturity, not necessarily code quality or adoption — but it means don't assume CNCF has vetted it the way it has Envoy or etcd.
• No public data on SLA, security audit cadence, or CVE response times. Check the GitHub security tab yourself before betting production auth on it.

Who should use this

• Platform teams standardizing Kubernetes cluster authentication (Dex + kube-apiserver OIDC flags is a well-worn pattern).
• Orgs with fragmented identity backends (LDAP for some teams, GitHub for engineers, SAML for enterprise SSO) who need one OIDC-shaped front door for internal tools.
• Teams already running Argo CD, Gitea, or other tools with native Dex/OIDC connectors — reduces integration work.
• Anyone who wants a self-hosted, no-license-fee OIDC broker and is comfortable operating it themselves.

Who should NOT use this

• Teams wanting a managed identity provider with support contracts and SLAs — Dex gives you none of that; you're the on-call.
• Orgs already fully committed to Okta, Auth0, Azure AD, or Google Workspace as their single source of truth with no legacy backend sprawl — you don't need a broker if you only have one upstream.
• Anyone needing SCIM provisioning, fine-grained RBAC policy management, or advanced adaptive auth (MFA risk scoring, etc.) — Dex is an auth broker, not an IAM platform. It won't do lifecycle management or governance.
• Teams uncomfortable running and patching security-critical infrastructure themselves — Sandbox-maturity + self-hosted means the operational and security burden is entirely on you.
• Compliance-heavy environments requiring vendor attestations (SOC2 reports from the tool vendor, etc.) — there's no vendor to hand you one.

Alternatives

• Keycloak — full IAM platform with its own user store, admin UI, and broader protocol support (SAML + OIDC natively); heavier but more batteries-included.
• Ory Hydra/Kratos — a more modular, API-first OAuth2/OIDC + identity stack if you want to build custom flows rather than use Dex's connector model.
• Okta / Auth0 (managed) — if you want someone else operating the identity layer and paying for support/SLAs, at the cost of it being closed and billed.

Pricing

Fully open source, Apache-2.0. No paid tier, no vendor, no support contract available. You self-host and self-support.