Introducing dex: CoreOS Open Source OpenID Connect Identity Provider

CoreOS Announces dex

CoreOS has released a new open‑source project called dex , an identity service component built on the OpenID Connect (OIDC) standard. It is already used in production on CoreOS’s own Tectonic.com platform. Authentication and authorization are essential for application security, and dex provides a powerful solution for these needs.

Key Design Elements

Security

Security is the top priority: dex follows best practices for encryption and minimizes the risk of attackers gaining system access. It uses short‑lived soft tokens, automatic signing‑key rotation, and encrypted keys, so an attacker would need to compromise both the database and a dex worker simultaneously.

Standards

dex implements the core OpenID Connect (OIDC) standard, which sits on top of OAuth 2 and offers a secure, easy‑to‑implement authentication protocol. OIDC is widely adopted by major internet companies such as Google, Facebook, and Amazon for single‑sign‑on.

Language and Platform Agnosticism

Because dex follows the OIDC core spec, integrating it into an application is straightforward: simply add an OIDC client library for your programming language. CoreOS provides a Go implementation called go-oidc , and similar libraries exist for most other languages.

Connectors (Union Identity)

dex defines a connector abstraction that allows authentication via different back‑ends. Out of the box it includes a local connector (email/password UI) and an OIDC connector (e.g., Google, Salesforce). Future plans include linking so a single user can log in via multiple methods, and additional connector types such as LDAP, GitHub, and SAML.

Case Study: Tectonic.com

At CoreOS, dex is used for Tectonic.com customer registration and authentication. When a user clicks the Join button, they are redirected to https://auth.tectoinc.com (the OIDC “Issuer URL”). They can sign in with a Google account or a username/password, after which they are sent back to Tectonic.com to complete registration.

Infrastructure diagram (illustrated in the original article) shows the components behind the firewall:

A PostgreSQL database serving as dex’s backend storage.

A dedicated dex‑overlord responsible for key rotation and other management tasks.

Multiple dex‑worker instances providing the front‑end for end‑user authentication.

The product site, Tectonic.com.

In the OIDC flow, the relying party (RP) – here the product site – exchanges an ID token with the identity provider (IdP), which is dex. When a user chooses Google authentication, dex temporarily acts as the RP while Google acts as the IdP; after the token exchange, dex resumes its role as IdP for Tectonic.com. All tokens are cryptographically signed, and signing keys are continuously rotated by the IdP and synchronized with the RP.

Future Plans for dex

dex is functional but still young. The roadmap includes:

Authorization – extending dex to serve as a generic authorization server.

User management – developing APIs (and eventually a UI) for administrators to manage users.

Multiple remote identities – allowing users to authenticate via various methods.

More connector types – such as LDAP, GitHub, etc.

Contributions are welcome for anyone interested in helping the project grow.

Original link: Announcing dex, an Open Source OpenID Connect Identity Provider from CoreOS (translation by Yao Hong).