feat(sso): self-service SSO config with DNS-verified domains by marksalpeter · Pull Request #13507 · langfuse/langfuse

marksalpeter · 2026-05-07T13:51:33Z

Summary

Org admins on Langfuse Cloud have no self-service path to configure SSO — the only path today is a Langfuse support engineer hitting /api/auth/add-sso-config with the ADMIN_API_KEY, and the Org Settings → SSO tab is a placeholder that opens the support drawer.

To achieve this we:

Added a VerifiedDomain model + tRPC router so orgs DNS-verify domain ownership (TXT record) before any SSO config can be created for that domain — closes the cross-tenant hijacking footgun.
Added an ssoConfig tRPC router (get / save / delete) that gates writes on a verified domain for the caller's org, encrypts clientSecret at rest, and emits before/after audit-log entries with the secret masked.
Pre-flight every save against the IdP's OIDC discovery doc — fetches <issuer>/.well-known/openid-configuration (or the equivalent for Azure AD / Google), validates the required fields and that the returned issuer matches what was configured. Catches mistyped issuer URLs and unreachable IdPs at save time instead of locking out users at first sign-in.
Replaced the placeholder SSO settings page with a per-domain list view + scoped setup form (provider picker, live callback URL panel, all 13 providers) and matching delete confirmation.
Tightened OIDC issuer validation to require https:// across every provider (also covers GitHub Enterprise's baseUrl) — catches a real footgun where Auth0/etc. issuers without a scheme broke at sign-in time instead of save time.
Query DNS for verification through Cloudflare / Google public resolvers so newly-added TXT records are visible within seconds instead of the system resolver's ~1-hour NXDOMAIN cache.

Note: GitHub and GitHub Enterprise are OAuth2-only with no .well-known endpoint, so the discovery pre-flight is skipped for those — misconfiguration there still surfaces at first sign-in. Cross-pod SSO config cache propagation lag (the "active within 1 hour" copy in the confirmation dialog) is tracked in LFE-9662.

Fixes LFE-9126

Verification

pnpm --filter web run typecheck
pnpm --filter web run lint
pnpm --filter web run test -- verifiedDomainRouter.servertest (15/15)
pnpm --filter web run test -- ssoConfigRouter.servertest (22/22, including 8 new discovery tests)
Browser pass — added domain, DNS-verified via Namecheap, configured Auth0 SSO, signed in via the new provider, updated credentials, deleted

Test plan

Verified Domains → Add domain → instructions show zone-relative host (_langfuse-verification) and copyable token → admin adds DNS record → Verify → row marks Verified.
Cross-tenant: a second org cannot add the same domain → CONFLICT error inline.
SSO tab → Configure SSO on a verified row → confirmation dialog warns about lockout → Save → row updates with provider summary.
Update flow pre-fills non-secret fields → clientSecret always required → Save replaces atomically.
Delete flow → confirmation → row reverts to "Not configured"; the other domain's config is untouched.
Form rejects an issuer like acme.us.auth0.com (missing https://) at validation time, not at sign-in.
Save with a mistyped issuer (e.g. wrong tenant on Azure AD, typo in Okta domain) is rejected with a clear discovery error at save time, not at sign-in.
GitHub provider: save succeeds without a discovery call (OAuth-only, skipped).
Member-role user (no organization:update) gets FORBIDDEN on every mutation.

Disclaimer: Experimental PR review

Greptile Summary

This PR introduces self-service SSO configuration for org admins on Langfuse Cloud, gated behind DNS-verified domain ownership. The implementation adds a VerifiedDomain model/router, a new ssoConfigRouter (get/save/delete) with clientSecret encryption and OIDC discovery pre-flight, and replaces the placeholder SSO settings page with a full domain-list + config form UI across 13 providers.

New VerifiedDomain table and tRPC router let org admins prove domain ownership via a DNS TXT record before any SSO config can be written; the Prisma migration adds appropriate unique and FK indexes.
ssoConfigRouter.save correctly requires a verified-domain claim, pre-flights the IdP's OIDC discovery document, encrypts clientSecret at rest, and emits masked audit logs; the delete handler's missing verifiedAt guard and the orphaned-SsoConfig problem on VerifiedDomain deletion were flagged in a prior review cycle.
The custom OIDC provider form path is silently broken: CustomProviderSchema requires authConfig.name but buildSsoPayload never includes it, so the Zod parse in handleConfirm fails and form.setError maps the error to a non-existent field — the user receives no feedback and the mutation is never called.

Confidence Score: 4/5

Safe to merge once the Custom OIDC form path is fixed — without it, custom provider saves silently fail in the UI with no user feedback.

The custom OIDC provider form never collects or sends the authConfig.name field that CustomProviderSchema requires; the resulting Zod validation failure in handleConfirm sets an error on a non-existent form field, silently swallowing the failure. This makes custom provider configuration completely non-functional through the UI. All other providers work correctly, the server-side security model is sound, encryption and audit logging are well-implemented, and the DNS-verification flow is solid.

web/src/ee/features/sso-settings/components/SSOSettings.tsx — the buildSsoPayload function and surrounding form code need a name field added for the custom provider case.

Security Review

SSRF via redirect following (validateSsoConfig.ts): fetch is called with redirect: \"follow\" against a user-supplied OIDC issuer URL. A redirect chain to an internal address (e.g. instance-metadata endpoints) will be silently followed; the issuer-equality check prevents body exfiltration but internal reachability is still leaked via error message differences. Switching to redirect: \"error\" closes this with no functional downside.

Important Files Changed

Filename	Overview
web/src/ee/features/sso-settings/components/SSOSettings.tsx	New SSO settings UI; `buildSsoPayload` omits required `name` field for the `custom` provider, causing silent save failures; `allowDangerousEmailAccountLinking` is hardcoded to `true` (flagged previously).
web/src/ee/features/multi-tenant-sso/server/ssoConfigRouter.ts	New tRPC router for SSO config CRUD; `save` correctly gates on `verifiedAt` and encrypts `clientSecret`; `delete` only requires any `VerifiedDomain` claim (not verified) — already flagged in prior review; `maskAuthConfig` consistently strips secret before returning or logging.
web/src/ee/features/verified-domains/server/verifiedDomainRouter.ts	New tRPC router for domain-ownership verification via DNS TXT record; TOCTOU race in `create` and no entitlement guard on mutations flagged; `delete` leaves associated `SsoConfig` as an orphan (already flagged).
web/src/ee/features/multi-tenant-sso/validateSsoConfig.ts	Server-side OIDC discovery preflight; correctly validates issuer match; `redirect: "follow"` allows the server to follow user-supplied redirects to internal endpoints — recommend `redirect: "error"`.
web/src/ee/features/verified-domains/components/VerifiedDomainsSettings.tsx	New Verified Domains UI component; RBAC and entitlement checks on client side; clean expandable row pattern for TXT record instructions; no logic issues found.
packages/shared/prisma/migrations/20260506144028_add_verified_domains/migration.sql	Adds `verified_domains` table with appropriate unique index on `domain`, `organization_id` FK with CASCADE delete, and index on `organization_id`; no issues.
web/src/ee/features/multi-tenant-sso/types.ts	Adds `oidcIssuer` Zod validator enforcing `https://` prefix across all provider schemas; all 13 providers correctly defined; no issues.
web/src/ee/features/verified-domains/server/dnsLookup.ts	Thin wrapper around Node.js `dns.Resolver` using Cloudflare/Google public resolvers; timeout and retry configured; no issues.

Sequence Diagram

sequenceDiagram
    participant Admin
    participant UI
    participant verifiedDomainRouter
    participant ssoConfigRouter
    participant validateSsoConfig
    participant DNS
    participant IdP

    Admin->>UI: Add domain
    UI->>verifiedDomainRouter: "create({ orgId, domain })"
    verifiedDomainRouter-->>UI: "{ recordHost, recordValue }"

    Admin->>DNS: Add TXT record
    Admin->>UI: Click Verify
    UI->>verifiedDomainRouter: "verify({ orgId, id })"
    verifiedDomainRouter->>DNS: resolveTxtFresh(_langfuse-verification.domain)
    DNS-->>verifiedDomainRouter: TXT records
    verifiedDomainRouter-->>UI: "{ verifiedAt }"

    Admin->>UI: Configure SSO (provider + credentials)
    UI->>ssoConfigRouter: "save({ orgId, payload })"
    ssoConfigRouter->>ssoConfigRouter: "check verifiedAt != null"
    ssoConfigRouter->>validateSsoConfig: validateSsoConfig(payload)
    validateSsoConfig->>IdP: GET issuer/.well-known/openid-configuration
    IdP-->>validateSsoConfig: discovery doc
    validateSsoConfig-->>ssoConfigRouter: ok / throws PRECONDITION_FAILED
    ssoConfigRouter->>ssoConfigRouter: encrypt(clientSecret)
    ssoConfigRouter->>ssoConfigRouter: upsert SsoConfig + auditLog
    ssoConfigRouter-->>UI: saved row (secret stripped)

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
web/src/ee/features/sso-settings/components/SSOSettings.tsx:644-691
**Custom OIDC provider is silently broken — `name` field missing from form and payload**

`CustomProviderSchema` requires `authConfig.name: z.string()` (non-optional), but `buildSsoPayload` never includes `name` in the payload for the `"custom"` case. When the user clicks "Activate SSO" with a Custom OIDC config, `SsoProviderSchema.safeParse` fails with `{ path: ["authConfig", "name"], message: "Required" }`. The error-display path then calls `form.setError("authConfig.name", ...)`, but `"authConfig.name"` is not a field in `formSchema`, so no error is shown. The confirmation dialog closes silently, `saveMutation.mutate` is never called, and the user has no idea why nothing happened. Add a `name` field to the form (and `formSchema`) for the `"custom"` provider case, and include it in `buildSsoPayload` for that branch.

### Issue 2 of 3
web/src/ee/features/multi-tenant-sso/validateSsoConfig.ts:67-72
Using `redirect: "follow"` on a server-side fetch to a user-supplied URL means the server will silently follow redirects to internal endpoints (e.g. a 302 from the OIDC discovery URL to `http://169.254.169.254/latest/meta-data/` or similar). While the issuer-equality check prevents data exfiltration from the response body, the server still establishes a connection to the redirect target, which leaks whether internal addresses are reachable. Setting `redirect: "error"` eliminates this vector with no functional cost — a legitimate IdP's discovery endpoint doesn't redirect.

```suggestion
  let resp: Response;
  try {
    resp = await fetch(discoveryUrl, {
      signal: AbortSignal.timeout(DISCOVERY_TIMEOUT_MS),
      redirect: "error",
    });
```

### Issue 3 of 3
web/src/ee/features/verified-domains/server/verifiedDomainRouter.ts:59-96
**`create` / `verify` / `delete` have no entitlement check**

Unlike `ssoConfigRouter`, none of the `verifiedDomainRouter` mutations call `throwIfNoEntitlement`. Any org — including `cloud:hobby` plans — can claim, DNS-verify, and delete domain ownership records. If entitlement enforcement is intentionally deferred to the `ssoConfig.save` call, this should be documented; otherwise a `throwIfNoEntitlement` call matching the one in `ssoConfigRouter` should be added here.

_{Reviews (2): Last reviewed commit: "feat(sso): pre-flight OIDC discovery on ..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.