Universal Login branding and authentication domains

Brand the shared login experience

Open Branding → Hosted Login. The workspace theme is shared across its hosted authentication experience. Customize identity assets, colors, typography, layout, card dimensions and text; inspect sign-in, registration, recovery and MFA at desktop and mobile sizes.

Try preview opens an expiring preview on the authentication surface, with a separate preview warning. It shows the theme outside the console and does not authenticate a user or issue application tokens. The universal branding preview is an appearance sample, not a guarantee that every displayed method is configured and available for a particular application. Its methods and sample states are distinct from a real application’s policy resolution.

Select Production or Sandbox, then save the theme when satisfied. Each environment persists its own theme in its dedicated identity database; no application is required. Uploaded logo and favicon images are retained with the theme. A confirmed save applies to subsequent hosted authentication page loads across that environment, including its custom authentication hostnames. Existing open pages keep the appearance they loaded.

An unsaved preview does not publish or persist a theme by itself. The editor loads the saved revision on entry and preserves your draft if a save fails. If another tab publishes first, reload and review that revision before reapplying your changes; a stale save cannot overwrite it. Theme changes are audited without recording image data in the audit event.

After saving, verify the actual application-initiated hosted flow, including its enabled methods, organization requirements and recovery screens. The same validated theme controls its presentation, while the real flow continues to enforce the application’s authentication policy. Check mobile overflow, label contrast, long translations and large logos when changing card dimensions.

The branding editor is configuration, not a public HTML/JavaScript injection surface. Keep the Oathvera provider attribution and required security controls intact. The attribution links to the Oathvera website in a new tab. This handbook documents the shared hosted-page and editor behavior.

Connect a custom authentication hostname

Use a dedicated subdomain such as login.example.test. Your application callbacks remain on your application; the custom hostname serves Oathvera’s authentication endpoints.

1. Open Branding → Custom Domains and add your hostname.
2. Publish the ownership TXT record and any certificate-validation records displayed by Oathvera. Keep the ownership record in place.
3. Wait for certificate readiness, then create the displayed DNS-only CNAME to customers.oathvera.app.
4. Refresh verification. Connected requires ownership, provider hostname/certificate readiness, expected routing and an HTTPS routing probe. DNS resolution alone is insufficient.
5. Copy the complete issuer shown for the domain: https://<your-hostname>/t/<tenant-id>.
6. Test discovery, new hosted authentication, callback exchange and API permission checks using that exact issuer before switching an integration.

Current onboarding permits up to five custom authentication hostnames per workspace and bounds creation attempts. It does not accept apex domains, wildcards, IP addresses, ports, private/internal names or reserved Oathvera hostnames. Use the records and status returned for your domain rather than copying another workspace’s verification values.

This process is independent of organization email-domain verification for enterprise SSO. It also does not create a separate deployment environment, dedicated database or Workers for Platforms runtime.

Treat a hostname change as an identity change

A different authentication hostname is a different issuer. Existing tokens and sessions stay tied to the issuer that created them. Pairwise subjects and passkeys also depend on the authentication hostname; a custom-domain move can require explicit identity mapping and new passkey enrollment.

Prepare a migration record containing the old and new issuers, affected clients, upstream social/enterprise callbacks, user-identity mapping, passkey enrollment path and rollback approach. Preserve stable application/client IDs and existing callbacks unless a deliberate integration change requires otherwise. Do not merge identities by email or silently accept any issuer arriving in a callback.

Keep the original authentication hostname available until the transition is accepted. Removing a custom domain removes routing authority and invalidates that domain’s token authority; provider cleanup may retry afterward. Removal is not an appropriate way to test a live customer’s rollback readiness.

The root of a connected authentication hostname may show connection information. A real sign-in begins at the authorization endpoint with a registered client, callback, state, nonce and PKCE. A branding preview URL is not an application login URL.