SpacetimeAuth: customizable hosted-auth pages (branding, theme, custom domain, configurable confirmation prompts)

Summary

SpacetimeAuth ships great OIDC infrastructure — the id_token doubles as the SpacetimeDB connection token, the flow is standard auth-code+PKCE, and react-oidc-context integrates cleanly. The gap is on the hosted auth pages at auth.spacetimedb.com/oidc/* — they're unbranded, can't be themed, can't be moved to a custom domain, and behaviours like the sign-out confirmation prompt aren't configurable per-app. For consumer apps with strong brand identity, the redirect to a generic-looking SpacetimeDB-branded page during sign-in is a noticeable brand break, and the back-and-forth with the IdP feels less like "you're signing into Acme" and more like "you're signing into SpacetimeDB."

This issue requests a path to brand-consistent hosted auth, ideally without forcing every app to self-host an IdP.

What's not customizable today (as far as I can find)

1. Visual theming of the sign-in / sign-up / consent / sign-out pages. No app-level CSS variables, logo upload, primary color, copy override, etc.
2. Custom domain for the auth host — every app's users see auth.spacetimedb.com in the URL bar during sign-in.
3. Sign-out confirmation page is only suppressible via the id_token_hint query param trick (works, but undocumented behavior). There's no per-client setting like "trust this app's logout request and skip the prompt."
4. Email templates (verification, password reset if/when relevant, magic-link etc.) — same SpacetimeAuth-branded copy for every consumer app.
5. Localization / copy override — the page strings are fixed.
6. Post-signup landing — every new user lands on a generic SpacetimeAuth confirmation; would be nice to redirect straight to the relying-party with a flag indicating "new account."

Proposed (rough sketch, in priority order)

1. Per-client theme on the SpacetimeAuth dashboard

Each OIDC client config (e.g. client_xxxx) gets a small theme object stored alongside redirect URIs:

client_id: client_xxxx
theme:
  primary_color: \"#1B4332\"
  background_color: \"#FAF9F7\"
  logo_url: \"https://thetea.today/brand/logo-cream.png\"
  display_name: \"The Tea\"
  font_family: \"system\"   # or one of a curated allowlist

Render the hosted pages with these values applied. Even shipping just display_name + logo + primary_color would cover ~80% of the brand-break problem.

2. Documented per-client behaviour switches

• skip_logout_confirmation: true — trust the relying-party's signoutRedirect and skip the "do you want to sign out?" page (instead of requiring the id_token_hint workaround).
• skip_consent_screen: true (where applicable) — for first-party apps that don't need user-facing scope consent.
• auto_redirect_after_signup: true — bounce new users back to the app immediately rather than showing the SpacetimeAuth "account created" confirmation.

3. Custom-domain CNAME for the auth host

auth.thetea.today → CNAME → auth.spacetimedb.com with TLS termination handled SpacetimeAuth-side. This is what every modern auth-as-a-service (Auth0, Clerk, WorkOS, etc.) provides; users see the relying-party's domain throughout the flow.

4. Email templates

Per-client subject + body override (or at minimum a sender-name override) for the standard transactional emails SpacetimeAuth sends. Variables for {{display_name}}, {{redirect_uri}}, {{magic_link}}, etc.

5. Embedded auth (lower priority)

A future option: react-oidc-context-compatible flow that lets the app render the password / passcode entry inline rather than redirecting. Most consumer auth providers offer both "hosted" and "embedded" SDK flows. This is more work, so the redirect-with-theming path above is the higher-priority ask.

Use case

Building a consumer-grade brand on top of SpacetimeDB. "The Tea" (https://thetea.today) is a women-first social platform with a strong visual identity (custom palette, fonts, illustration). When a new user clicks "get me in" on the invitation screen they get redirected to a generic SpacetimeAuth login page, and the brand drops on the floor for the duration of the auth flow.

We've documented the id_token_hint workaround for the sign-out prompt internally because it's the difference between a clean logout and an extra confirmation page that breaks the flow — that workaround works but isn't a substitute for a real configuration story.

Environment

• Backend: SpacetimeDB Maincloud
• SpacetimeAuth client: standard OIDC code flow + PKCE (via react-oidc-context)
• Versions: spacetimedb 2.2.0 SDK, CLI 2.2.0

Start by locating the SpacetimeAuth hosted pages at auth.spacetimedb.com/oidc/* and the per-client configuration represented in the SpacetimeAuth dashboard. Review how the OIDC code flow, sign-out confirmation, and react-oidc-context integration currently work. Done would require narrowing this broad request into an agreed, implementable scope with corresponding configuration, hosted-page behavior, and tests.