Loading post…
ClickhouseAnnouncement
Introducing JWT authentication in ClickHouse Cloud
Summary
ClickHouse Cloud now supports JWT authentication for services running version 26.4 or later, allowing short-lived tokens from OpenID Connect providers such as Okta and Microsoft Entra to replace long-lived passwords. When a client presents a token, ClickHouse verifies its signature and claims, then creates an ephemeral in-memory user with the roles and grants specified in the token. The user disappears after the token’s expiration, removing the need for CREATE USER or DROP USER commands. Roles are managed once in ClickHouse and assigned via token claims; identity and group membership are governed by the provider. The feature also handles definer views by writing persistent shadow users, and it supports RS256 keys from version 26.4 and EC keys from version 26.8.
Approach / What changed
ClickHouse Cloud Services running 26.4 or later verify JWT tokens from an OpenID Connect provider against the provider’s JWKS URL. On a valid token, ClickHouse creates an ephemeral in-memory user with the roles and grants carried in the token. The user exists only while the token is valid and is removed after the token’s exp passes. Identity and roles are managed entirely in the provider; no CREATE USER or DROP USER is needed in ClickHouse. Roles such as analyst or pipeline_writer are created once in ClickHouse and assigned to users via token claims like clickhouse:roles.
Takeaways
JWT authentication eliminates the need to create, provision, or drop database users; an ephemeral user is created in memory upon first valid token presentation and removed after token expiration, with no disk writes or backup inclusion.
Roles such as analyst or reader are created once in ClickHouse and assigned to tokens via the clickhouse:roles claim; the identity provider controls group membership, so onboarding is a group assignment and offboarding is removing it.
For definer views created by a JWT user, ClickHouse writes a persistent shadow user named with a “:definer” suffix that holds the creator’s rights at creation time, ensuring the view continues to work after the original token expires.
FAQ
How does JWT authentication change user lifecycle in ClickHouse?
A JWT user appears in memory the first time a valid token is presented and is removed by a background task after the token’s expiration time passes. The user is never written to disk and is not included in backups. CREATE USER, ALTER USER, and DROP USER do not apply; the token lifecycle is the user lifecycle.
How are quotas and row policies applied to JWT users?
Roles, quotas, and row policies can be attached to a role that the token carries, such as analyst. Since the token dictates role membership, any policy attached to that role automatically applies to every user presenting a token with that role. Per-user assignments can also be applied to the ephemeral JWT user, stored in Keeper, and survive token expiration and user re-creation.
How do definer views work when the creator is an ephemeral JWT user?
When a JWT user creates a definer view, ClickHouse writes a persistent shadow copy of the user with a “:definer” suffix, holding the creator’s rights at that moment. The view runs as the shadow user and continues working after the original token expires and the ephemeral user is removed.
Source and freshness
- Source
- clickhouse.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.