dex

OpenID Connect (OIDC) identity and OAuth 2.0 provider with pluggable connectors

10,039

1,827

10,039

473

View on GitHub

Top Related Projects

keycloak

27,937

Open Source Identity and Access Management For Modern Applications and Services

The only web-scale, fully customizable OpenID Certified™ OpenID Connect and OAuth2 Provider in the world. Become an OpenID Connect and OAuth2 Provider over night. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters. Relied upon by OpenAI and others for web-scale security.

oauth2-proxy

11,694

A reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.

zitadel

11,359

ZITADEL - Identity infrastructure, simplified for you.

authelia

24,840

The Single Sign-On Multi-Factor portal for web apps, now OpenID Certified™

Quick Overview

Dex is an identity service that uses OpenID Connect to drive authentication for other apps. It acts as a portal to other identity providers, allowing you to use multiple authentication methods (LDAP, SAML, etc.) with a single, consistent interface. Dex is designed to be a foundational building block for identity management in cloud-native environments.

Pros

Supports multiple identity providers (IdPs) including LDAP, SAML, and OAuth2
Provides a consistent OpenID Connect interface for client applications
Highly extensible and customizable
Well-suited for Kubernetes and cloud-native environments

Cons

Requires some technical expertise to set up and configure
Documentation can be sparse in some areas
May be overkill for simple authentication needs
Limited built-in user management features

Code Examples

Configuring a client in Dex:

staticClients:
- id: example-app
  redirectURIs:
  - 'http://127.0.0.1:5555/callback'
  name: 'Example App'
  secret: ZXhhbXBsZS1hcHAtc2VjcmV0

Using Dex with Go OAuth2 client:

import "golang.org/x/oauth2"

config := oauth2.Config{
    ClientID:     "example-app",
    ClientSecret: "ZXhhbXBsZS1hcHAtc2VjcmV0",
    RedirectURL:  "http://127.0.0.1:5555/callback",
    Scopes:       []string{"openid", "profile", "email"},
    Endpoint:     provider.Endpoint(),
}

// Redirect user to Dex login page
url := config.AuthCodeURL(state)
http.Redirect(w, r, url, http.StatusFound)

Verifying an ID token in Go:

import "github.com/coreos/go-oidc/v3/oidc"

ctx := context.Background()
provider, err := oidc.NewProvider(ctx, "https://dex.example.com")
verifier := provider.Verifier(&oidc.Config{ClientID: "example-app"})

// Parse and verify ID Token
idToken, err := verifier.Verify(ctx, rawIDToken)
if err != nil {
    // Handle error
}

Getting Started

Install Dex:

git clone https://github.com/dexidp/dex.git
cd dex
make

Create a configuration file (e.g., config.yaml):

issuer: http://127.0.0.1:5556/dex
storage:
  type: sqlite3
  config:
    file: examples/dex.db
web:
  http: 0.0.0.0:5556
staticClients:
- id: example-app
  redirectURIs:
  - 'http://127.0.0.1:5555/callback'
  name: 'Example App'
  secret: ZXhhbXBsZS1hcHAtc2VjcmV0

Run Dex:
```
./bin/dex serve config.yaml
```
Integrate Dex with your application using the OpenID Connect protocol.

Competitor Comparisons

keycloak

27,937

Open Source Identity and Access Management For Modern Applications and Services

Pros of Keycloak

More comprehensive identity and access management solution with built-in user management, role-based access control, and social login
Offers a user-friendly admin console for easier configuration and management
Supports multiple protocols including OpenID Connect, SAML, and OAuth 2.0

Cons of Keycloak

Heavier resource footprint and more complex setup compared to Dex
Steeper learning curve due to its extensive feature set
May be overkill for simpler authentication scenarios

Code Comparison

Dex configuration example:

issuer: https://dex.example.com
storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db
web:
  http: 0.0.0.0:5556

Keycloak configuration example:

auth-server-url: https://keycloak.example.com/auth
realm: myrealm
resource: myclient
public-client: true
ssl-required: external

Both projects provide flexible configuration options, but Keycloak's configuration tends to be more extensive due to its broader feature set. Dex focuses primarily on identity brokering and OIDC, while Keycloak offers a more comprehensive IAM solution with additional features and protocols.

hydra

16,408

Pros of Hydra

More comprehensive OAuth2 and OpenID Connect implementation
Advanced security features like JSON Web Key rotation
Higher performance and scalability for large-scale deployments

Cons of Hydra

Steeper learning curve due to more complex architecture
Requires additional setup and configuration compared to Dex
Less focus on identity provider integration out-of-the-box

Code Comparison

Hydra configuration example:

serve:
  public:
    port: 4444
  admin:
    port: 4445
urls:
  self:
    issuer: https://hydra.example.com/
  consent: https://consent.example.com/consent
  login: https://login.example.com/login
  logout: https://login.example.com/logout

Dex configuration example:

issuer: https://dex.example.com/dex
storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db
web:
  http: 0.0.0.0:5556
connectors:
  - type: github
    id: github
    name: GitHub
    config:
      clientID: $GITHUB_CLIENT_ID
      clientSecret: $GITHUB_CLIENT_SECRET
      redirectURI: https://dex.example.com/dex/callback

Both Hydra and Dex are popular open-source identity and access management solutions. Hydra offers a more comprehensive OAuth2 and OpenID Connect implementation with advanced features, while Dex focuses on simplicity and easy integration with various identity providers. The choice between the two depends on specific project requirements, scalability needs, and the desired level of customization.

oauth2-proxy

11,694

A reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.

Pros of OAuth2 Proxy

Simpler setup and configuration for basic use cases
Supports a wider range of OAuth2 providers out-of-the-box
Lightweight and easy to deploy as a single binary

Cons of OAuth2 Proxy

Less flexible for complex identity management scenarios
Limited support for custom claims and scopes
Lacks built-in identity brokering capabilities

Code Comparison

OAuth2 Proxy configuration example:

providers:
  - provider: github
    client_id: <client-id>
    client_secret: <client-secret>
    scope: user:email

Dex configuration example:

connectors:
- type: github
  id: github
  name: GitHub
  config:
    clientID: <client-id>
    clientSecret: <client-secret>
    redirectURI: http://127.0.0.1:5556/dex/callback

Both projects serve as authentication proxies, but Dex focuses on being an identity provider and federation service, while OAuth2 Proxy is primarily a reverse proxy with OAuth2 authentication. Dex offers more advanced features like identity brokering and support for multiple backends, making it suitable for complex enterprise scenarios. OAuth2 Proxy, on the other hand, is simpler to set up and use for basic authentication needs, especially when working with popular OAuth2 providers.

zitadel

11,359

ZITADEL - Identity infrastructure, simplified for you.

Pros of Zitadel

More comprehensive identity management solution, offering features like user management and multi-tenancy out of the box
Built-in UI for user management and administration
Supports multiple programming languages and frameworks natively

Cons of Zitadel

Steeper learning curve due to more complex architecture and features
Less flexibility for custom integrations compared to Dex's modular approach
Requires more resources to run and maintain

Code Comparison

Dex (Go):

func (s *Server) HandlePublicKeys(w http.ResponseWriter, r *http.Request) {
    // Handle public keys endpoint
}

Zitadel (Go):

func (h *Handler) HandlePublicKeys(w http.ResponseWriter, r *http.Request) {
    // Handle public keys endpoint with additional features
}

Both projects use similar patterns for handling HTTP requests, but Zitadel's implementation often includes more complex logic to support its broader feature set.

authelia

24,840

The Single Sign-On Multi-Factor portal for web apps, now OpenID Certified™

Pros of Authelia

Offers a more comprehensive authentication solution with built-in 2FA, single sign-on, and access control
Provides a user-friendly web portal for authentication and account management
Supports multiple storage backends for user information, including LDAP and SQL databases

Cons of Authelia

More complex setup and configuration compared to Dex
Less focused on identity federation and OAuth2/OpenID Connect protocols
May have a steeper learning curve for administrators new to advanced authentication systems

Code Comparison

Authelia configuration (YAML):

access_control:
  default_policy: deny
  rules:
    - domain: secure.example.com
      policy: two_factor

Dex configuration (YAML):

issuer: https://dex.example.com
storage:
  type: sqlite3
  config:
    file: /var/dex/dex.db

Both projects use YAML for configuration, but Authelia's configuration tends to be more detailed due to its broader feature set. Dex focuses primarily on identity federation and OAuth2/OpenID Connect, while Authelia offers a wider range of authentication and access control options.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

dex - A federated OpenID Connect provider

GitHub Workflow Status

logo

Dex is an identity service that uses OpenID Connect to drive authentication for other apps.

Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.

ID Tokens

ID Tokens are an OAuth2 extension introduced by OpenID Connect and dex's primary feature. ID Tokens are JSON Web Tokens (JWTs) signed by dex and returned as part of the OAuth2 response that attests to the end user's identity. An example JWT might look like:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjlkNDQ3NDFmNzczYjkzOGNmNjVkZDMyNjY4NWI4NjE4MGMzMjRkOTkifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiQ2djeU16UXlOelE1RWdabmFYUm9kV0kiLCJhdWQiOiJleGFtcGxlLWFwcCIsImV4cCI6MTQ5Mjg4MjA0MiwiaWF0IjoxNDkyNzk1NjQyLCJhdF9oYXNoIjoiYmk5NmdPWFpTaHZsV1l0YWw5RXFpdyIsImVtYWlsIjoiZXJpYy5jaGlhbmdAY29yZW9zLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJncm91cHMiOlsiYWRtaW5zIiwiZGV2ZWxvcGVycyJdLCJuYW1lIjoiRXJpYyBDaGlhbmcifQ.OhROPq_0eP-zsQRjg87KZ4wGkjiQGnTi5QuG877AdJDb3R2ZCOk2Vkf5SdP8cPyb3VMqL32G4hLDayniiv8f1_ZXAde0sKrayfQ10XAXFgZl_P1yilkLdknxn6nbhDRVllpWcB12ki9vmAxklAr0B1C4kr5nI3-BZLrFcUR5sQbxwJj4oW1OuG6jJCNGHXGNTBTNEaM28eD-9nhfBeuBTzzO7BKwPsojjj4C9ogU4JQhGvm_l4yfVi0boSx8c0FX3JsiB0yLa1ZdJVWVl9m90XmbWRSD85pNDQHcWZP9hR6CMgbvGkZsgjG32qeRwUL_eNkNowSBNWLrGNPoON1gMg

ID Tokens contains standard claims assert which client app logged the user in, when the token expires, and the identity of the user.

{
  "iss": "http://127.0.0.1:5556/dex",
  "sub": "CgcyMzQyNzQ5EgZnaXRodWI",
  "aud": "example-app",
  "exp": 1492882042,
  "iat": 1492795642,
  "at_hash": "bi96gOXZShvlWYtal9Eqiw",
  "email": "jane.doe@coreos.com",
  "email_verified": true,
  "groups": [
    "admins",
    "developers"
  ],
  "name": "Jane Doe"
}

Because these tokens are signed by dex and contain standard-based claims other services can consume them as service-to-service credentials. Systems that can already consume OpenID Connect ID Tokens issued by dex include:

For details on how to request or validate an ID Token, see "Writing apps that use dex".

Kubernetes and Dex

Dex runs natively on top of any Kubernetes cluster using Custom Resource Definitions and can drive API server authentication through the OpenID Connect plugin. Clients, such as the kubernetes-dashboard and kubectl, can act on behalf of users who can login to the cluster through any identity provider dex supports.

More docs for running dex as a Kubernetes authenticator can be found here.
You can find more about companies and projects which use dex, here.

Connectors

When a user logs in through dex, the user's identity is usually stored in another user-management system: a LDAP directory, a GitHub org, etc. Dex acts as a shim between a client app and the upstream identity provider. The client only needs to understand OpenID Connect to query dex, while dex implements an array of protocols for querying other user-management systems.

A "connector" is a strategy used by dex for authenticating a user against another identity provider. Dex implements connectors that target specific platforms such as GitHub, LinkedIn, and Microsoft as well as established protocols like LDAP and SAML.

Depending on the connectors limitations in protocols can prevent dex from issuing refresh tokens or returning group membership claims. For example, because SAML doesn't provide a non-interactive way to refresh assertions, if a user logs in through the SAML connector dex won't issue a refresh token to its client. Refresh token support is required for clients that require offline access, such as kubectl.

Dex implements the following connectors:

Name	supports refresh tokens	supports groups claim	supports preferred_username claim	status	notes
LDAP	yes	yes	yes	stable
GitHub	yes	yes	yes	stable
SAML 2.0	no	yes	no	stable	WARNING: Unmaintained and likely vulnerable to auth bypasses (#1884)
GitLab	yes	yes	yes	beta
OpenID Connect	yes	yes	yes	beta	Includes Salesforce, Azure, etc.
OAuth 2.0	no	yes	yes	alpha
Google	yes	yes	yes	alpha
LinkedIn	yes	no	no	beta
Microsoft	yes	yes	no	beta
AuthProxy	no	yes	no	alpha	Authentication proxies such as Apache2 mod_auth, etc.
Bitbucket Cloud	yes	yes	no	alpha
OpenShift	yes	yes	no	alpha
Atlassian Crowd	yes	yes	yes *	beta	preferred_username claim must be configured through config
Gitea	yes	no	yes	beta
OpenStack Keystone	yes	yes	no	alpha

Stable, beta, and alpha are defined as:

Stable: well tested, in active use, and will not change in backward incompatible ways.
Beta: tested and unlikely to change in backward incompatible ways.
Alpha: may be untested by core maintainers and is subject to change in backward incompatible ways.

All changes or deprecations of connector features will be announced in the release notes.

Documentation

Getting started
Intro to OpenID Connect
Writing apps that use dex
What's new in v2
Custom scopes, claims, and client features
Storage options
gRPC API
Using Kubernetes with dex
Client libraries
- Go

Reporting a vulnerability

Please see our security policy for details about reporting vulnerabilities.

Getting help

For feature requests and bugs, file an issue.
For general discussion about both using and developing Dex:
- join the #dexidp on the CNCF Slack
- open a new discussion
- join the dex-dev mailing list

Development

When all coding and testing is done, please run the test suite:

make testall

For the best developer experience, install Nix and direnv.

Alternatively, install Go and Docker manually or using a package manager. Install the rest of the dependencies by running make deps.

For release process, please read the release documentation.

License

The project is licensed under the Apache License, Version 2.0.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot