ClickHouse Cloud now supports JWT authentication using short-lived tokens from an OpenID Connect identity provider, so teams can grant database access without creating a persistent database user for every person or workload. The practical shift is that identity and roles stay with the provider, while access in ClickHouse expires with the token.
ClickHouse Watch analysis
What happened
ClickHouse says services running version 26.4 or later can accept JWTs from an existing OIDC provider, including Okta and Microsoft Entra. A token identifies the user and service, carries its expiry and can include existing ClickHouse roles. ClickHouse verifies the token, creates an ephemeral user in memory and applies the roles and grants it contains.
For teams using their own identity provider, setup requires the Enterprise plan. Administrators configure the provider’s issuer, audience and public HTTPS JWKS address in the Cloud console; the token’s roles must match roles already created in ClickHouse. ClickHouse says it checks the JWKS address when it is saved, which should catch a typo before anyone’s first login. Its JWT authentication guide covers setup and client usage.
Why it matters
Database passwords and certificates can leave teams managing a sprawling collection of credentials: issuing them, storing them, rotating them and revoking them when access changes. With JWT authentication, the identity provider decides who gets which roles, and the token’s expiry ends that access. ClickHouse says the ephemeral user is removed after expiry and is not written to disk.
That changes the database-side routine, too. Teams create roles once, then assign them through the identity provider rather than provisioning and removing a persistent database user for every person or workload. The feature is available to Enterprise customers using their own OIDC provider, so the plan requirement belongs in the decision, not in the fine print.
Our read
This is a useful security and operations improvement: fewer persistent credentials to manage, with access tied to a token that expires. For administrators, the practical starting point is to check the service version and plan, then confirm that provider claims map cleanly to existing ClickHouse roles. Short-lived access is a good tool, not a substitute for deciding carefully what those roles are allowed to do.
What to watch
- Whether ClickHouse expands custom OIDC-provider support beyond Enterprise.
- How teams handle token refresh and role changes in their clients and identity providers.
- Whether operators can make the move without disrupting existing user policies and workflows.
Discussion spark: Should database access be controlled primarily through short-lived identity-provider tokens, or do persistent database users still make more sense for some teams?
Sources and evidence
- Source update (8 October 2026, 13:55 UTC)
not affiliated with or endorsed by ClickHouse