Skip to main content

Announcing dex, an Open Source OpenID Connect Identity Provider from CoreOS

Today we are pleased to announce a new CoreOS open source project called dex: a standards-based identity provider and authentication solution.

Just about every project requires some sort of authentication and user-management. Applications need a way for users to log-in securely from a variety of platforms such as web, mobile, CLI tools and automated systems. Developers typically use a platform-dependent solution or, just as often, find existing solutions don't quite address their needs and so they resort to writing their own solution from scratch.

Most developers are not in the security business, however. Having to write their own authentication software is not only an annoying distraction from their core product, but it can be downright dangerous as well. Doing security correctly is tricky, as we’ve seen with the many recent high-profile breaches, and doing it in a vacuum without proper auditing by other engineers and security experts is even more risky.

For these reasons, we have decided to open source dex so that others may benefit from the work we’ve done to make dex a secure and robust platform. Now available to the community, dex in turn will benefit from having more stakeholders. No one will ever have to write their own "Forgot your password?" flow, or “Login with X, Y or Z” feature again.

The project is named 'dex' because it is a central index of users that other pieces of software can authenticate against.

Key Design Elements

What makes dex unique is the combination of the following elements, which has driven the design and implementation from the beginning.


First and foremost is security: dex is designed using security and encryption best practices that minimize the risk of an attacker gaining access to the system. Furthermore, the dex architecture is compartmentalized to mitigate the damage that any single attack could incur. For example, dex defaults to short token lifetimes and rotates its signing keys automatically. Since the keys themselves are encrypted at rest, an attacker would need to compromise both the database and a dex worker within a short time in order to forge a token.


dex is an implementation of the OpenID Connect (OIDC) Core spec. OIDC (not to be confused with OpenID) was created in partnership with a wide variety of industry leaders and security experts, building on years of experience in web security. It is a layer on top of OAuth2, and as such provides a secure, easy-to-implement protocol for authentication. Today OIDC is used as the single sign-on approach for internet giants like Google, Facebook or Amazon.

Language/Platform Agnostic

Because dex implements the OpenID Connect (OIDC) Core spec, it is easy to integrate dex into your application. The only step is to add an OIDC client library in your language of choice. We’ve written one in Go called go-oidc; others exist in almost every language (be sure to vet any client libraries to ensure proper signature validation and spec compliance).

Identity Federation

dex has its own concept of users, but it allows them to authenticate in different ways, called connectors. Right now, dex ships with two types of connectors: the local connector and the OIDC connector. When authenticating with the local connector, users log-in with an email and password with a customizable UI provided by dex itself. With the OIDC connector, users authenticate by logging into another OIDC Identity Provider, like Google or Salesforce.

Since dex itself is an OIDC Identity Provider it is even possible to chain multiple dex instances together, each delegating authentication to the next in line.

Currently users must choose between connectors, but in the future we plan allow for the linking of identities, so any individual user can log-in in a variety of ways. The extensible connector architecture will allow for integrations with providers like GitHub, LDAP and SAML systems.

Case Study:

One way we are using dex at CoreOS is to register and authenticate customers of Tectonic. When a user first decides to become a Tectonic customer and clicks the “Join” button, they are taken to, which is the “issuer URL” in OpenID Connect parlance. They are asked to register either by using their Google identity or entering in a name and password. After this they are redirected back to the main site where they can complete their signup.

Below is a diagram outlining the deployment:

dex infrastructure diagram
dex Infrastructure Diagram
Behind our firewall, we have several components:
  • a postgres database serving as dex’s backing store
  • a single dex-overlord, responsible for rotating keys and other administrative tasks
  • several dex-workers, which provide the front-end for end-user authentication
  • our product site,

In OIDC the Relying Party (RP) – in this case, our product site – exchanges an Authorization Token (obtained from the end-user, the Tectonic customer) for an ID token, with the Identity Provider (IdP), which is dex. Note that although we have our application and dex co-located behind the same firewall, it is not necessary. They communicate with each other over the public Internet via a TLS connection; this can be useful if you have a variety of applications in different hosting environments all needing authentication.

When a user chooses to authenticate using their Google account, dex temporarily becomes the RP and Google becomes the IdP for the purposes of authenticating and identifying the user. Once dex has done this (via the same token exchange protocol mentioned above), dex goes back to being the IdP and completes the token exchange with

Throughout the process tokens are cryptographically signed, and signatures verified by the clients. Signing keys are constantly rotated by the IdPs and synced by the RPs.

Future Plans with dex

dex is usable right now, but there’s still a lot of work to do. Aside from the open issues on GitHub, things that are on the roadmap for dex include:

  • Authorization – In addition to dex handling authentication, we’d like it to be a general purpose authorization server as well.
  • User Management – We are in the beginning stages of developing an API for admins to manage users, but soon it will be more complete and come with UI as well.
  • Multiple Remote Identities – As mentioned above, users will be able to authenticate using more than one authentication method.
  • Additional Connector types – Eg., LDAP and GitHub

dex is still quite young, and there’s a lot of work to do going forward, so if you’re interested, we’d love to have your help!