Token Auth

Use token auth when your app should send Authorization: Bearer <token> on every request instead of raw user/password credentials.

KalamDB supports two token sources:

• internal JWTs returned by POST /v1/api/auth/login
• external OIDC JWTs from trusted issuers such as Firebase or Keycloak

Internal Token Flow

The built-in login flow is:

1. Send user and password to POST /v1/api/auth/login.
2. Receive access_token and refresh_token.
3. Send the access token on API and WebSocket requests.
4. Refresh it through POST /v1/api/auth/refresh when needed.

Login

1curl -X POST http://127.0.0.1:2900/v1/api/auth/login \2  -H 'Content-Type: application/json' \3  -d '{"user":"admin","password":"AdminPass123!"}'

Typical response fields:

• access_token
• refresh_token
• expires_at or token-expiry metadata
• authenticated user profile fields

Use the access token

1TOKEN="<access_token>"2 3curl -X POST http://127.0.0.1:2900/v1/api/sql \4  -H "Authorization: Bearer $TOKEN" \5  -H 'Content-Type: application/json' \6  -d '{"sql":"SELECT CURRENT_USER();"}'

Refresh Tokens

1REFRESH="<refresh_token>"2 3curl -X POST http://127.0.0.1:2900/v1/api/auth/refresh \4  -H "Authorization: Bearer $REFRESH"

Use the returned access token for subsequent requests.

Checking Auth State

There are two practical checks:

Check the current authenticated user

1curl http://127.0.0.1:2900/v1/api/auth/me \2  -H "Authorization: Bearer $TOKEN"

This confirms whether the token is accepted and shows the current user record.

Check from SQL

1curl -X POST http://127.0.0.1:2900/v1/api/sql \2  -H "Authorization: Bearer $TOKEN" \3  -H 'Content-Type: application/json' \4  -d '{"sql":"SELECT CURRENT_USER();"}'

This is the fastest way to confirm the runtime identity that SQL sees.

External Provider Tokens

If you already have a JWT from Firebase, Keycloak, or another trusted OIDC issuer, skip the login endpoint and send that token directly as a bearer token.

KalamDB will:

1. read alg and iss
2. reject untrusted issuers
3. perform OIDC discovery for the issuer
4. fetch and cache the issuer JWKS
5. validate the token signature and claims
6. resolve or create the matching local user

Provider setup details live in:

• OIDC & Issuer Trust
• Firebase
• Keycloak

SDK Pattern

For long-lived apps, return a fresh token from the SDK auth provider callback instead of hard-coding a token once.

TypeScript

1import { Auth, createClient, type AuthProvider } from '@kalamdb/client';2 3const authProvider: AuthProvider = async () => {4  const token = await myApp.getOrRefreshJwt();5  return Auth.jwt(token);6};7 8const client = createClient({9  url: 'https://db.example.com',10  authProvider,11});

Dart

1final client = await KalamClient.connect(2  url: 'https://db.example.com',3  authProvider: () async {4    final token = await myApp.getOrRefreshJwt();5    return Auth.jwt(token);6  },7);

Configuration Notes

Internal token auth still depends on a strong shared secret:

1[authentication]2jwt_secret = "replace-with-strong-random-secret-32-plus-chars"3cookie_secure = true

Use KALAMDB_JWT_SECRET in production instead of committing secrets to server.toml.

Related

• Authentication Overview
• Auto-Provisioning Users
• HTTP API Reference
• Authentication & Bootstrap