Dex: Open‑Source Federated Identity Provider for Modern DevSecOps

TL;DR, What is Dex?

Dex is an OpenID Connect (OIDC) identity provider that acts as a federated identity broker for your applications.

If you’re on a DevSecOps team, you know the struggle of managing authentication across different systems like LDAP, SAML, and GitHub. It often leads to complex integrations and a clunky user experience. Dex solves this problem by acting as a central hub. Instead of connecting each app to every identity provider, your applications only need a single OIDC integration with Dex. Dex then handles the federated authentication to your various backends, giving you a streamlined and secure single sign-on (SSO) experience and simplifying tasks like Kubernetes authentication.

Originally developed by CoreOS, Dex is now a Cloud Native Computing Foundation (CNCF) sandbox project, which highlights its importance in modern application ecosystems.

Kubernetes Security Best Practices [Cheat Sheet]

This 6 page cheat sheet goes beyond the basics and covers security best practices for Kubernetes pods, components, and network security.

Your work email here

Download cheat sheet

At-a-Glance

• URL: https://github.com/dexidp/dex

• License: Apache-2.0

• Primary Language: Go

• Stars: 10.1k

• Last Release: May 2025

• Topics/Tags: kubernetes, OpenID Connect, OAuth 2.0, Identity Provider, Federated Identity, SSO

Common use cases

1. Centralized Kubernetes Authentication: You can use Dex as an OIDC provider to centralize Kubernetes authentication using client tools like kubelogin. Developers and CI/CD systems authenticate against Dex, which then federates to a corporate IDP like LDAP or SAML. This simplifies user management and helps you enforce consistent RBAC policies across clusters.

2. Single Sign-On (SSO) for Internal Tools: You can implement a seamless SSO experience for internal web applications, dashboards, and microservices. A Dex SSO configuration allows applications to delegate authentication, which reduces credential fatigue for users and simplifies development by offloading security concerns to a central service.

3. Bridging Legacy and Cloud-Native Systems: Dex can act as an identity bridge, connecting traditional enterprise directories like LDAP to modern cloud-native applications that expect OIDC. This lets you leverage existing identity investments while adopting new technologies without complex, custom integrations.

4. Secure API and Service-to-Service Communication: You can leverage Dex for securing interactions between microservices. Services can get OIDC tokens from Dex, either for themselves or on behalf of a user, and use them to securely call other internal APIs, ensuring all service-to-service traffic is properly authenticated.

5. Self-Contained Authentication for Small Deployments: For projects that don’t have an existing external identity provider, you can configure Dex to use its own internal user store. The gRPC API allows for programmatic management of these local users, providing a lightweight, self-contained authentication solution for smaller applications.

How does Dex work?

Dex acts as an identity hub, using the OIDC protocol to centralize authentication for your applications. When a user logs into a client app, they are redirected to Dex. Dex's web UI presents a login page, allowing the user to choose their preferred identity provider, like GitHub or LDAP.

After the user authenticates with that upstream provider, Dex verifies their identity, generates its own standardized OIDC tokens, and sends the user back to the original application, now successfully logged in.

• Dex Server: The core component that functions as an OpenID Connect (OIDC) provider, handling authentication requests and issuing tokens

• Connectors: Pluggable modules that integrate with upstream identity providers (IDPs); each connector understands a specific protocol (e.g., SAML, LDAP) to communicate with services like Google or GitHub

• Storage: A persistence layer backed by etcd or SQL databases for storing client configurations, refresh tokens, and user sessions, supporting various robust backends

Kubernetes Security for Dummies

Everything you need to know about securing Kubernetes

Your work email here

Download now

Core Capabilities:

1. Federated Identity Management: Dex shines at federated identity management, letting your applications authenticate users against external providers like LDAP, SAML, and social logins. It handles all the tricky parts of different authentication protocols and gives your client applications one unified OpenID Connect (OIDC) interface. By acting as an identity broker, Dex centralizes authentication logic, reduces the integration work for individual apps, and helps you enforce consistent security policies. The pluggable connector architecture also makes it highly adaptable to your existing enterprise setup.

2. OpenID Connect (OIDC) Provider: Dex is a complete OpenID Connect provider, built on the OIDC specification to work with any compliant client application. After a successful login, it issues standard ID Tokens with verifiable user identity claims and Access Tokens for securing resources. Because it’s a standards-based approach, you get broad interoperability with the cloud-native ecosystem and a robust, widely adopted protocol for secure authentication.

3. Pluggable Connector Architecture: Dex’s flexible design is built around pluggable connectors, which let you easily connect to various upstream identity systems. These systems can include traditional enterprise solutions like LDAP and Active Directory, as well as cloud-based identity providers and OAuth 2.0 services. This means you can easily configure Dex to use your existing identity infrastructure, ensuring user authentication relies on established directories without needing data migration or complex sync processes.

4. OAuth 2.0 Token Exchange: To give you more flexibility in distributed systems, Dex supports the OAuth 2.0 Token Exchange specification (RFC 8693). This token exchange feature allows a service to swap an existing token, like one from an upstream IDP, for a new token issued by Dex. This is especially useful for delegation and impersonation scenarios where a service needs to act on behalf of a user or get a token with different scopes, helping secure interactions in complex microservice architectures.

5. Programmatic Administration via gRPC API: Beyond its core OIDC functionality, Dex gives you a gRPC API for programmatic administration and management. The gRPC API lets you automate tasks like creating and managing local users and passwords, registering OIDC clients, and controlling other operational aspects. This is a great way to integrate Dex into your infrastructure-as-code workflows, giving you granular, automated control over its configuration without manual work.

Limitations

1. Not a Comprehensive Identity Provider: Dex is primarily an identity broker, not a full-featured identity provider. Its internal user storage capabilities are basic and don't have the advanced features of systems like Active Directory or Okta, such as complex password policies, user lifecycle management, or a user-facing portal.

2. Requires Operational Expertise: As a critical piece of security infrastructure, Dex requires careful operational management. Deploying it for high availability, managing storage backends, handling TLS certificates, and configuring connectors all require a solid understanding of its architecture, so there can be a steep learning curve.

3. Limited Native Authorization Features: Dex is great at authentication (verifying who you are) but provides minimal built-in authorization features (what you're allowed to do). It passes identity information and group memberships in its tokens, but it’s up to your downstream applications or a separate service to handle fine-grained access control.

4. Lacks Administrative UI: Dex does not ship with a built-in administrative web interface. All configuration and management tasks, such as registering clients or managing local users, must be performed through static configuration files or programmatically via its gRPC API, which can be less accessible for non-developer administrators.

5. Stateful Component Dependency: Dex is a stateful service that requires a persistent storage backend (e.g., PostgreSQL, etcd) to store client secrets, refresh tokens, and other operational data. This dependency adds an external component that must be deployed, managed, secured, and backed up, which increases the overall complexity of your system architecture.

wiz academy

The top 11 open-source Kubernetes security tools

Read more

Getting Started:

Step 1:

To get started with Dex, you can download a release from GitHub or build it from source. If you’re building, make sure you have Go installed. Clone the repo and build Dex:

git clone https://github.com/dexidp/dex.git
cd dex
go build ./cmd/dex

Step 2:

Once it’s built, create a configuration file (e.g., config.yaml). Then start Dex:

./dex serve config.yaml

You’ll find Dex running on the configured port (default: 5556). Be sure to check the official documentation for instructions on configuring connectors and integrating with your identity provider.

From federated login to least privilege

Dex brokers secure authentication. Wiz enriches that identity layer with vulnerabilities, configurations, and data sensitivity to help enforce true zero-trust in the cloud.

Work Email*

First Name*

Last Name*

Country

Phone Number*

Company*

Keep me updated about Wiz product releases, industry news, and events (You can unsubscribe at any time)

Subscribe me to the Wiz blog digest emails

Submit

For information about how Wiz handles your personal data, please see our Privacy Policy.

Your work email here

Get a demo

Alternatives

FAQs