Status: Accepted for the MVP — with an explicit fit review before
further chat investment · Date: 2026-07-23 · Deciders: Ronen,
Michael (alignment meeting)
Note (2026-07-31): product reviewed the shipped portal→chat
integration (plain external link, TKF-48) and accepted it. The no-iframe
decision stands — LibreChat actively resists embedding, and
re-implementing parts of it in the portal was explicitly rejected
("not now").
The out-of-the-box stack ships a chat surface so a freshly installed Token
Factory is immediately usable by non-engineers. LibreChat is deployed today
(stock image, chart-configured, gateway-only endpoint — TKF-23, verified on
the dev rig). The alignment meeting settled how deeply it should integrate:
- Ronen: the bundled experience must feel like one product — a
consolidated login story and a way into chat from the portal. He is
explicitly "not married to LibreChat"; it was chosen for being cool and
useful, and should remain swappable.
- Michael: in the field, chat tools and key management are often owned by
different teams — customers bring Open WebUI, n8n, editors, agents. The
gateway-key model must stay tool-agnostic.
Both are true, so the product story is: bundled chat, integrated; every
other tool, bring-your-own via API keys.
- Keep LibreChat as the bundled chat surface for the MVP (unchanged).
- Integrate it: OIDC against the platform Keycloak
(TKF-24), a chat entry point in
the portal (TKF-48), and later
per-team chat service keys
(TKF-49).
- BYO tools are first-class: any OpenAI-compatible client works with a
gateway key + endpoint. The chat surface is one consumer, never a
dependency of the platform.
Research + an empirical spike on the AWS demo env answered the open
questions:
- OIDC: yes. Full OpenID support (
OPENID_* envs: PKCE, end-session
logout, required-role gating via realm_access.roles, and a token-reuse
mode where Keycloak's tokens become the session). Verified live against
our Keycloak on the AWS env: SSO button, flow initiation, and discovery
all worked — up to one hard requirement: the issuer must be HTTPS
(openid-client v6 policy; plain http needs a code patch, and we do not
fork). Non-issue for real installs (enterprise = https); the http demo
env enables chat SSO when it gains TLS. Chart support is merged behind
oidc.enabled + chat.publicUrl (DOMAIN_SERVER/CLIENT are required for
redirects).
- Credential model: workable. Native per-USER keys via
apiKey: user_provided (users paste their portal-minted key — perfect
gateway-side attribution, zero new infra). Custom-endpoint headers accept
{{LIBRECHAT_USER_ID}}/{{LIBRECHAT_USER_EMAIL}} placeholders for
attribution on a shared key. Automatic per-TEAM key injection (TKF-49) is
NOT native — options ranked in that ticket; forwarding the OIDC access
token to endpoints is not supported today.
- Embedding: no; link: yes. Not designed for iframing (CSP/frame
headers) — the portal entry point (TKF-48) is a plain link, which was the
acceptable outcome.
- Ops: good. MIT license, active release cadence, and everything we've
needed so far (branding overlay, endpoint config, SSO) was config-only —
the no-fork rule holds.
- The fallback got worse. Open WebUI left BSD-3 for a custom license
(2025): keeping its branding is mandatory above 50 users/30 days without
an enterprise license, plus a CLA — a poor fit for a white-label channel
product. This materially strengthens the LibreChat choice.
Verdict: LibreChat stays. Revisit only if the per-team credential work
(TKF-49) hits a wall that user_provided + portal keys cannot cover.
- Chat integration work (TKF-24/48/49) is scoped tool-agnostically where
possible; LibreChat-specific effort stays minimal until the review lands.
- The umbrella chart treats chat as swappable: config + branding overlay
only, no code dependency in either direction.