Tenant branding

1. In Admin → Branding, select the user pool whose end users should see the brand.
2. Set the display name and public HTTPS support, privacy, and optional help links.
3. Choose separate light- and dark-mode accent colours. Combinations that cannot produce readable text and controls are rejected.
4. Optionally upload a PNG or WebP logo, no larger than 256 KiB or 2,048 pixels on either side. Mark decorative artwork as decorative; otherwise supply useful alt text.
5. Save a draft, review the preview in both colour modes, and publish the version.
6. Enable the published version separately for hosted pages and authentication email.

Drafting and publishing are separate on purpose. A saved draft cannot change a live sign-in page, and a prior published version remains available for an explicit rollback.

• Hosted authentication: display name, logo, accessible light/dark accent treatment, and support, privacy, and help destinations.
• Email → Appearance: the same published display identity, logo, links, and colour treatment when that surface is enabled.
• Sending identity: configured separately. The inbox sender name and noreply@auth.<your-domain> address do not change merely because a presentation brand changes.

• The Authreads security disclosure cannot be removed. It tells a user which service is handling credentials and recovery, reducing the value of a tenant brand as a phishing disguise.
• Generic failure pages use the platform style. Some failures occur before a tenant can be resolved safely; guessing a brand at that boundary could disclose or display the wrong tenant.
• Admin and Console are never tenant-branded. They are operator security surfaces, so their identity must stay stable while an operator changes or diagnoses a tenant brand.
• Layout, typography, credential controls, and security copy are fixed. Stable interaction and contrast boundaries prevent a brand configuration from hiding, moving, or imitating security-critical controls.

Your OpenID Connect issuer, discovery document, authorization and token endpoints, userinfo and logout endpoints, client credentials, and exact registered redirect and post-logout URIs stay canonical. The hostname that serves the interactive login page is a separate provider concern. A later change to that hostname requires no application configuration switch or callback migration.

The browser can move between the canonical authorization endpoint and the hosted login page during sign-in. Treat that as expected provider navigation: do not add the login-page hostname to your issuer, redirect allowlist, application CSP, cookie domain, or callback handling. A tenant-specific login hostname is not currently an integrator-managed capability, so do not create DNS or proxy rules for one.

If your product owns its login UI instead, use the direct server-mediated flow described in Sessions & tokens. In that model your product owns the page and its presentation, while the authentication API owns credential validation and session issuance.

Enabling a surface points it at one immutable published version. If that version or a referenced asset cannot be resolved, the surface fails visibly instead of substituting the platform brand. Disable the affected surface deliberately to return it to platform presentation, or repair and republish the tenant brand.