Dex
Capability scores
Methodology →- Authentication
- 4.0
- SSO & Federation
- 4.0
- Authorization
- 2.5
- Lifecycle & Provisioning
- 2.0
- MFA & Passwordless
- 2.5
- Governance & Audit
- 2.5
- Developer Experience
- 4.0
- Deployment Flexibility
- 4.5
- Pricing Transparency
- 5.0
- Support & Ecosystem
- 3.5
Scored 0–5 against a published rubric. Independent analysis, no vendor sponsorship.
Overview
Dex is an open-source OpenID Connect provider that federates to existing identity sources: applications talk OIDC to Dex, and Dex authenticates users against LDAP, GitHub, an upstream OIDC provider or another backend through "connectors," then issues signed ID tokens. CoreOS started it in 2016, and it was accepted into the CNCF at the Sandbox level on 25 June 2020, where it remains. It is Apache 2.0 licensed with no commercial owner; the GitHub repository had about 11,200 stars and shipped v2.46.1 on 21 October 2026. It is best known as the standard way to put SSO in front of the Kubernetes API server.
What it is good at
It does one job and keeps the footprint small. A single Go binary, configured in YAML, can store state in Kubernetes custom resources, etcd, SQLite, PostgreSQL or MySQL, so it runs inside a cluster without a separate database. The Kubernetes guide covers API server OIDC authentication with kubectl and kubelogin, and Dex passes upstream group membership into the groups claim, which maps cleanly to Kubernetes RBAC. The LDAP and GitHub connectors are marked stable and support refresh tokens and groups; GitLab, Microsoft and generic OIDC connectors are beta. A gRPC API manages clients and local passwords programmatically. For platform teams it removes the need to teach every internal tool about every identity source.
Where it falls short
It is a broker, not an identity platform. There is no admin console, no self-service registration or password reset, no SCIM provisioning, and no MFA documented in Dex itself, so second factors must be enforced upstream. Connector maturity varies: Google, generic OAuth 2.0, Bitbucket and Gitea are alpha, which Dex defines as possibly "untested by core maintainers." The biggest caveat is SAML. Dex's SAML connector page warns that it is "unmaintained, likely vulnerable to authentication bypass vulnerabilities" and under consideration for deprecation, and it cannot issue refresh tokens. That matters because many enterprise IdPs are wired up over SAML 2.0; prefer their OIDC endpoint. Support is community-only, with no vendor SLA.
Pricing
Free and open source under Apache 2.0, self-hosted. The real cost is the engineering time to run, upgrade and monitor it, which for a typical Kubernetes deployment is small. No paid edition exists.
Best for, and who should look elsewhere
Choose Dex when users already live in an IdP or directory and you need a lightweight OIDC front door for Kubernetes, Argo CD-style internal tools or CLI sign-in: a working deployment is usually a day of Helm values and connector configuration. Look elsewhere if you need a user store, MFA, an admin UI or SAML identity-provider features; Keycloak, Zitadel and authentik are full IdPs (Keycloak vs Zitadel). For workload rather than human identity in clusters, see the Kubernetes identity security guide.
Bottom line
The default lightweight OIDC broker for Kubernetes and internal tooling, as long as you federate over OIDC or LDAP rather than its unmaintained SAML connector. It complements an identity provider; it does not replace one.
Dex: frequently asked questions
- What is Dex used for?
- Dex is an OpenID Connect provider that sits between your applications and existing identity sources. Applications speak only OIDC to Dex, and Dex authenticates the user against an upstream system through a connector, such as LDAP, GitHub, GitLab, Microsoft or another OIDC provider, then issues signed ID tokens. Its most common use is Kubernetes API server authentication with kubectl and kubelogin, and single sign-on for internal platform tools.
- Is the Dex SAML connector safe to use?
- Treat it as a last resort. Dex's own documentation warns that the SAML connector is unmaintained, likely vulnerable to authentication bypass, and under consideration for deprecation, and recommends OpenID Connect, OAuth 2.0 or LDAP where the upstream supports them. It also cannot issue refresh tokens, which breaks offline clients such as kubectl. If your IdP offers OIDC, use the OIDC connector instead.
- Does Dex store users or support MFA?
- Mostly no. Users normally live in the upstream directory or IdP, and Dex documents no MFA of its own, so multi-factor authentication has to be enforced by the upstream provider. Dex does have a built-in local password connector, useful for bootstrapping or tests, but there is no admin console, self-service registration, password reset or SCIM provisioning.
- Dex vs Keycloak: which should I pick?
- Pick Dex when you already have an identity source and need a small, stateless OIDC front door, especially for Kubernetes. Pick Keycloak, or Zitadel or authentik, when you need a full identity provider with a user store, admin UI, MFA, SAML identity-provider support and fine-grained client management. Keycloak does far more, and costs far more to run and upgrade.
Related on Start with Identity
- CVESMB Server Kerberos reflection via Ghost SPNs
October 2025 follow-on to CVE-2025-33073. SMB Server elevation of privilege by combining Kerberos reflection with Ghost SPNs and DNS self-registration.
- CVEWindows SMB Client improper authentication (tampering)
Windows SMB Client improper authentication (CWE-287) that allows tampering. Not an Entra token bug, but it sits in the same Microsoft identity-adjacent patch tr
- CVEWindows SMB Kerberos reflection elevation of privilege
Kerberos authentication reflection on SMB, still abusable via Ghost SPNs after the first fix. High-severity elevation of privilege on Windows.
- VendorCasdoor
emerging
- VendorFreeIPA
established
By SWI Community Team · Last evaluated 2026-10-31
Independent, community-driven analysis. No vendor sponsorship. Compiled from public research and community input and verified on a best-effort basis, so details may be incomplete or out of date. Scores are opinions, not advice. Trademarks belong to their owners; mention does not imply affiliation or endorsement. See the full disclaimer, or send corrections to community@startwithidentity.com.