Single OIDC Provider Model
KalamDB’s active external auth model is issuer-based, not provider-family-based.
That means:
- one KalamDB server process supports one configured external OIDC provider
- the provider is identified by
auth.oidc.issuerandauth.oidc.client_id - there is no built-in provider enum, provider prefix table, or provider-specific username format in the active model
Dex, Keycloak, Okta, Auth0, Entra ID, Google, Firebase, and similar services all fit this same shape as long as they expose standards-compliant OIDC discovery.
The Current server.toml Shape
No Provider Matrix
The current docs and backend surface should not talk about:
[oauth][oauth.providers.*]- provider name lists such as
keycloak,firebase,auth0, and so on - provider-code username formats such as
oidc:kcl:<subject>
Those were part of an older design. The active model is a single configured OIDC issuer.
How External Users Are Identified
External users use the provider sub claim directly as the KalamDB user_id. The same value is used by SQL identity, system.users.user_id, and PG extension EXECUTE AS USER '<user_id>'.
Subjects must be valid KalamDB user IDs: ASCII letters, digits, _, or -, up to 128 characters. If the provider emits unsafe subject characters, normalize that at the IdP layer before using it with KalamDB.
Persisted OIDC users store the issuer and subject, and the subject must match the row’s user_id:
Auto-Provision And Explicit Users
Regular users can authenticate without a per-user row when:
auth.oidc.auto_provision = trueauth.oidc.default_role = "user"
Elevated roles should be explicit. Example: