explaingit

dexidp/dex

10,807GoAudience · ops devopsComplexity · 4/5Setup · hard

TLDR

A self-hosted Go service that acts as a single login layer for your apps, letting users authenticate via GitHub, Google, LDAP, Active Directory, or other providers through one standard OpenID Connect interface.

Mindmap

mindmap
  root((Dex))
    What it does
      Single login layer
      Issues signed tokens
      Connects providers
    Identity providers
      GitHub Google
      LDAP Active Directory
      SAML GitLab
    How it works
      OpenID Connect out
      Connectors in
      Kubernetes CRDs
    Audience
      DevOps teams
      Platform engineers
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Let users log into your internal app with their existing GitHub or Google account without building separate OAuth integrations for each provider.

USE CASE 2

Wire Dex into a Kubernetes cluster so developers authenticate using the company's existing LDAP or Active Directory system.

USE CASE 3

Replace multiple identity integrations across microservices with one Dex deployment that issues standardized OpenID Connect tokens all services can trust.

Tech stack

GoOpenID ConnectSAMLKubernetes

Getting it running

Difficulty · hard Time to first run · 1h+

Requires a running database, a Kubernetes or server environment, and credentials for each identity provider you want to connect.

In plain English

Dex is a Go service that sits in the middle of the login process for your applications. Instead of building separate login integrations for GitHub, Google, LDAP, Active Directory, and so on, your app makes a single connection to Dex, and Dex handles talking to whichever identity system is actually storing the users. The core idea is that Dex speaks one language outward (OpenID Connect, a widely supported standard for user authentication) and many languages inward. Those inward connections are called connectors. Dex ships with connectors for LDAP directories, SAML providers, GitHub, GitLab, Google, Microsoft, LinkedIn, Bitbucket, Atlassian Crowd, Gitea, OpenShift, OpenStack Keystone, and others. When a user logs in, Dex contacts the appropriate connector, verifies the user against that backend, and then issues an ID Token to your application. An ID Token is a signed JSON document that says who the user is, when the token was issued, and when it expires. Because these tokens are digitally signed by Dex and follow the OpenID Connect standard, other systems can trust and consume them without contacting Dex again. Kubernetes is a prominent example: Dex can be wired into a Kubernetes cluster so that developers authenticate against whatever existing identity provider an organization already uses. Dex is designed to be deployed inside infrastructure you control, rather than as a third-party cloud service. It runs natively on Kubernetes using Custom Resource Definitions, and it stores client configurations and connector settings in a database you manage. The project is part of the Cloud Native Computing Foundation ecosystem. Documentation, configuration guides, and setup instructions are at dexidp.io.

Copy-paste prompts

Prompt 1
I want to set up Dex so my internal web app lets users log in with their GitHub account. Show me a minimal Dex config.yaml with a GitHub connector.
Prompt 2
How do I deploy Dex on Kubernetes using Custom Resource Definitions to manage connectors and OAuth clients without restarting the pod?
Prompt 3
My company uses LDAP for user management. How do I configure the Dex LDAP connector to authenticate users against our directory server?
Open on GitHub → Explain another repo

← dexidp on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.