Integrations
This section covers external tools and identity/storage integrations.
KalamDB’s current auth surface supports one external OIDC provider at a time. Dex is the recommended local and CI-friendly test issuer in the current docs set. *** Add File: /Users/jamal/git/KalamSite/content/server/integrations/dex.mdx
title: “Dex” description: “Use Dex as a local or test OpenID Connect provider for KalamDB, including server.toml config, Admin UI login, and CLI browser/device flows.”
Dex
Dex is the simplest supported way to test KalamDB’s current OIDC flow locally.
Use Dex when you want:
- a small standards-compliant OIDC issuer for local development
- repeatable browser and device-flow testing for the Admin UI and CLI
- a test IdP that matches KalamDB’s single-provider OIDC model
Local Dex Setup
The KalamDB repo already includes a Dex container and config:
Default local Dex values from the shared development config:
- issuer:
http://127.0.0.1:5556 - public client ID:
client - Admin UI callback:
http://127.0.0.1:2900/ui/oauth/callback - CLI browser callback:
http://127.0.0.1:8787/callback - test user:
alice@example.org - test password:
kalamdb123
KalamDB server.toml Example
For the public Dex client used in local development, leave client_secret unset.
Admin UI Login
Make sure the Dex client allows this redirect URI:
Then open the Admin UI, choose the OIDC login button, and sign in as alice@example.org with password kalamdb123.
CLI Login
Browser login
This uses the local browser callback at http://127.0.0.1:8787/callback.
Direct device login
Use this when you want to stay headless and let the CLI complete provider device flow directly.
Brokered device login
Enable brokered mode only when the CLI host cannot reach Dex directly but can reach KalamDB.
Notes On Production Use
Dex can be used beyond local development, but production use is an operational choice, not a KalamDB requirement.
Dex is a good fit when:
- you control the deployment environment
- you manage TLS, connector configuration, storage, and backups yourself
- you want a lightweight self-hosted OIDC layer
Many teams still prefer an existing enterprise IdP for production. From KalamDB’s perspective, that is fine because the runtime only cares about one configured OIDC issuer.