Dex

Dex acts as a bridge between an application and the organization's existing login systems. The application speaks OpenID Connect to Dex; Dex uses a connector to authenticate the user with a provider such as a directory or another identity service. It is useful when several applications need a consistent login interface despite different upstream providers. Login establishes identity, while each application must still decide what the signed-in user is allowed to do.

Deployment and operating notes

Dex remains an OpenID Connect identity service that connects applications to upstream identity providers. Its project-owned Helm chart and current connector documentation supersede the archived stable package and the old table of alpha, beta and claim support. Connector behavior, especially groups and refresh tokens, must be checked for the chosen connector and version.

Inventory issuer URL, client IDs, redirect URIs, signing-key storage and upstream provider configuration before migration. Preserve persistent storage where it contains keys or sessions, and avoid changing the issuer URL casually because relying applications validate it. Test authorization-code login, token refresh, group changes, denied users and expiry with the actual client applications. A memory-backed demonstration setup is not evidence of durable multi-replica operation. Keep TLS and cookie behavior consistent through the ingress path, and restrict administrative interfaces. A successful authentication response does not prove the application applies the intended authorization policy; verify a low-privilege identity before switching all clients.