Open-source SSO for Kubernetes compared

A kubectl login starts with a client-side tool such as kubelogin, which opens a browser, sends the user to the identity provider, and receives tokens back. The API server never sees the password or the browser session. It only checks the ID token presented in each request, using the OIDC settings in its own startup configuration: --oidc-issuer-url, --oidc-client-id, and the claim mappings for the username and groups. The issuer URL must match the iss value in the token exactly, and the API server must be able to reach that issuer's discovery document and signing keys over the network. Whether Dex, Keycloak or authentik sits behind the issuer, the same checks apply, so confirm the issuer, client ID, and claim names in your own cluster before you blame the identity provider for a failed login.

Refresh tokens matter because ID tokens are short-lived. A kubectl session that needs to keep working past the token lifetime, or a script that must run without someone present, depends on the client receiving a refresh token and exchanging it for new ID tokens. Dex's README states that it issues no refresh token when a user logs in through its SAML connector, because SAML has no non-interactive way to refresh assertions. The practical result is that a team using SAML upstream may find that users must log in again whenever their token expires. Test the exact connector and client combination you plan to use, and confirm the token lifetimes and offline access settings in your environment, since this behavior depends on the connector and client configuration rather than on the cluster alone.

Before you commit to a design, run a test login through each candidate and check three things: that the API server accepts the ID token, that the refresh token is issued and renewed, and that group claims arrive in the form your RBAC bindings expect. Keep the issuer's TLS certificate chain available to the API server, because a trust failure there looks like a generic authentication error. Record the results against the connector you intend to use in production, not against a demo login with a local account, so that the verdict reflects the path your users will actually take.

The effort of running Keycloak in a cluster starts with its database. Keycloak needs a relational database in production, and its default dev-file database is not suitable for production. Plan for the database as a separate component with its own backup, patching and failover, and confirm which of the supported engines your platform team already runs. The Keycloak Operator is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. Because the operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources, you should set manual approval mode for operator updates so that upgrades happen when your team chooses. Keycloak also migrates its database schema automatically at startup by default. Test that migration against a copy of production data, and consider the manual migration path the upgrading guide suggests for large deployments. If you need high availability, both supported designs require a synchronously replicated database, which is often the largest single cost driver in the design.

authentik has a smaller component list but a different dependency profile. A deployment runs a server container with core and an embedded outpost, a worker container for background tasks, and PostgreSQL, which holds all configuration and data except uploaded files. Since the 2025.10 release, authentik no longer uses Redis, and caching, tasks, sessions and WebSocket functions run on PostgreSQL instead. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, so check your connection limits and any pooler before you move a cluster from an older release that still depends on Redis. Confirm with your platform team whether they already operate PostgreSQL with the capacity to absorb this load. Also check the enterprise boundary early, because Google Workspace, Microsoft Entra ID and enhanced audit logging sit behind the paid edition.

Dex is the lightest option on this list, and its storage choice determines most of its operating work. Dex can store state in etcd v3, Kubernetes CRDs, PostgreSQL or MySQL 5.7 or later. The Dex documentation says CRDs may not suit a large number of users, so teams with many users should not default to them. SQLite3 is only for standing Dex up quickly, not for real workloads, so treat it as a trial setting and plan a migration to etcd, CRDs or a database before any shared use. Because Dex owns no user state, your effort is mostly in connector configuration and in keeping the upstream identity provider reachable, not in running a user store. Confirm with your identity team which upstream connector you will use, since the README marks the SAML 2.0 connector as unmaintained and warns of likely auth bypasses.

Switching the SSO option behind a running cluster is mostly a change to the trust relationship between the Kubernetes API server and its identity issuer. Every cluster that authenticates users through OIDC carries the issuer URL and client ID in its API server flags or structured authentication configuration, so moving from Dex to Keycloak or authentik means changing that setting on every control plane, rolling the API server restarts in a planned window, and confirming that group and username claims still map to the same RBAC bindings. Each cluster is a separate change, so the count of clusters, not the count of users, usually drives the effort. Ask your platform team to list every cluster, its API server configuration source, and every RBAC binding that depends on a claim name before you commit to a switch.

The second cost is on the user side. Kubeconfig files, kubelogin settings and any scripts that hold the issuer URL or client secret must be reissued or updated, and users with cached refresh tokens will need to log in again. Dex's storage determines what can move cleanly: Dex stores its state in etcd, Kubernetes CRDs, SQLite3, PostgreSQL or MySQL, and its own documentation warns that CRD storage may not suit a large number of users. Dex also owns no user store, so its user records live in the upstream connector. Moving to Keycloak or authentik therefore means recreating users, groups and client registrations in the new issuer, or federating them from the same LDAP or Active Directory source, and testing that the claims the cluster expects still arrive. Treat that migration as a project with its own test plan, not a configuration edit. (Illustrative: a team with a small number of clusters and a single LDAP source will face a far smaller change than one with many clusters and per-team connectors.)

Plan the exit before go-live by keeping the issuer, client ID and claim mapping in version-controlled configuration, and by documenting which upstream connector each user comes from. Keep a tested fallback path, such as a break-glass certificate or service account, so an issuer outage or a failed switch does not lock administrators out of the API server. Ask any implementation partner for the written scope to cover cluster-by-cluster cutover steps, rollback criteria and the post-switch verification of RBAC, and confirm how refresh token behavior changes between the old and new issuer, since Dex issues no refresh token for SAML logins and kubectl depends on refresh tokens for offline access.