Vord

Enhancement Proposal

Proposal: Hosted login experience and branding (Universal Login)

The ADRs decided the issuer; they did not decide the login experience. A raw OIDC endpoint without hosted, brandable, localized login/registration/MFA/recovery pages is not competitive with Auth0 Universal Login or Okta's hosted sign-in. This is a feature on the admission plane (Modgud, ADR-0009) governed by realm policy (ADR-0012) — no new architecture.

Motivation

Centralising the login UX at the IdP is both a product requirement (CIAM apps need a polished, branded, localized sign-in) and a security win: credentials are entered in exactly one place, which is phishing-resistant (passkey origin-binding, ADR-0020), consistently hardened, and never copied into per-app login forms.

Design

  • Hosted ceremonies at Modgud (ADR-0009): login, registration, MFA challenge and enrollment, consent, recovery (proposal 0003), and error pages — all served by the IdP, not the relying party.
  • Per-realm branding (ADR-0012): logo, colors, theme/CSS, custom copy, and localization (multiple languages), so each tenant or app presents its own identity. This proposal is the owner of localization/i18n for the hosted UIs — notification templates (proposal 0011) and accessibility's language/RTL requirements (proposal 0020) reference the mechanism here rather than growing their own.
  • Custom domains: serve auth from the relying party's own domain (e.g. auth.customer.com). The routing fits the existing edge/regional topology (ADR-0024); the one operational dependency is automated certificate provisioning (ACME), noted but not new architecture. One consequence is a reserved seat (proposal 0001): a custom domain changes the realm's issuer (iss) and its discovery/JWKS URLs — a Vör-visible, token-format-adjacent decision that must be made at M4, and before WebAuthn passkeys bind to realm origins (ADR-0020); this corrects the earlier "no token change" framing.
  • Messaging (verification/reset/OTP) is delivered through the notification provider (proposal 0011) and shares the branding/localization.

Alternatives considered

  • Embedded / SDK-only login as the primary path — rejected: it fragments credential entry across apps, widens the phishing surface, and is harder to harden uniformly. (An embedded SDK may still wrap the hosted flow.)
  • Per-app login forms — rejected for the same reason.

Graduation criteria

A realm can fully brand and localize all hosted ceremonies; a custom domain serves auth with an auto-provisioned certificate; login, MFA, recovery, and consent are consistent and centrally hardened.

Backward compatibility

A feature on Modgud + realm policy; no API or architecture change — with the one correction above: a custom domain moves the realm's iss and discovery/JWKS URLs, a Vör-visible seat decided at M4, before passkey origin binding (ADR-0020). Custom-domain certificate provisioning is a deployment concern (ADR-0024).

Open questions

  • Theming model: config vs CSS vs templates (without becoming code-execution).
  • Custom-domain certificate automation and tenant-domain verification.