Richer hosted authentication themes

Hosted identity pages used a thinner color set than the rest of the product. Sign-in could look on-brand while magic-link, TOTP, and consent drifted. Environments now share one configurable palette across those flows, with live previews in the branding console.

This is the longer note behind the May 13 changelog entry.

How it works

Theme colors persist as JSON on applications_environments_configurations.theme_palette. Storage is either a legacy flat object (light only) or a bundle with light and dark overrides.

Semantic slots are:

background, foreground, muted
card, border, link
primary, onPrimary

Empty keys keep the built-in default for that slot. Values must be hex, rgb/rgba, or hsl/hsla. url(, expression(, comments, and var( are rejected before CSS is emitted.

The same palette is applied on hosted sign-in, sign-up, magic-link, TOTP, MFA, forgot-password, and the Account Portal. Header and body fonts, layouts (theme_layout_login, theme_layout_signup), and light/dark flags travel with the same environment configuration.

The branding console splits the stored bundle for live preview so you can judge light and dark without deploying.

Set it up

In the Authdog console, open Branding:

Choose the project and environment.
Set light (and optional dark) palette colors.
Preview sign-in and sign-up in the designer.
Save, then open the hosted Account Portal and walk magic-link or TOTP if those methods are enabled.

A visible preview is not a published theme until you save.

Trust boundaries

Theme CSS is decoration. It does not change authentication policy, captcha, or token issuance. Sanitization stops injected CSS functions; it is not a substitute for keeping untrusted operators out of environment write access.

Dark overrides only apply when dark mode is enabled for the environment.

Try it

Change primary and card, save, and reload hosted sign-in. Branding overview is on Authentication. The original release note is in the changelog.