Enterprise SSO: login form should offer SSO as a first-class option, not require email entry

[yokoszn]

Module

@open-mercato/enterprise → sso module
File: packages/enterprise/src/modules/sso/widgets/injection/login-sso/widget.client.tsx

Summary

The SSO sign-in option is invisible on /login until the user types a complete email and waits out the 300ms HRD debounce. There is no visual cue that SSO is available on this instance at all. New users have no way to discover that SSO is the intended login path — they try the password form first, get confused, and bounce.

Current behavior

1. User loads /login
2. Page shows only: email, password, "Remember me", "Sign in", "Forgot password?"
3. User types user@twn.systems
4. Debounced POST /api/sso/hrd fires after 300ms
5. Only then: password hides, banner "SSO is enabled for this account" appears, button flips to "Continue with SSO"

Problems

• Zero discoverability: A user who just wants to SSO in has no indication it exists. They attempt password login, fail, then may or may not realize they needed to type their email first.
• Demo / notice banners intercept pointer events: The fixed-position demo notice at the bottom of the login page blocks clicks on the "Continue with SSO" button until dismissed. Repro: /login with DEMO_MODE=true, type SSO-enabled email, try to click the button — click is swallowed by the banner's subtree.
• Domain-based HRD is not a substitute for an SSO button. An IdP-branded button ("Continue with Logto", "Continue with your company SSO") is the universal pattern (Okta, Auth0, Clerk, Keycloak, WorkOS all do this).

Proposed solution

Add configuration on SsoConfig (or a global toggle) so an admin can choose one of:

1. HRD-only (current behavior) — only shows SSO after email domain match.
2. Always visible — SSO button is rendered unconditionally when at least one active SsoConfig exists for the tenant. Multiple configs → provider picker / "Continue with SSO" that opens HRD. Single config → direct "Continue with SSO" button above or below the password form.
3. SSO-first / SSO-only — password form is hidden or collapsed behind "Use password instead"; SSO button is the primary CTA.

Minimum viable: a new column on sso_configs like loginButtonVisibility: 'hrd' | 'always' | 'primary' (default hrd for back-compat), with a matching admin UI toggle in the SSO config form.

Additionally, fix the banner z-index / pointer-events so fixed footer notices don't swallow clicks on the submit button.

Affected files (source repo)

• packages/enterprise/src/modules/sso/widgets/injection/login-sso/widget.client.tsx — render unconditionally when config allows
• packages/enterprise/src/modules/sso/data/entities.ts — add loginButtonVisibility column
• packages/enterprise/src/modules/sso/migrations/ — new migration
• packages/enterprise/src/modules/sso/backend/sso/config/[id]/page.tsx — admin toggle
• packages/core/src/modules/auth/frontend/login.tsx — pointer-events for the notice bar

Discovered while

Setting up Logto SSO for twn.systems on a downstream app. Even after the config was active and HRD worked, the login page rendered no SSO affordance until after typing a domain — which sent me debugging a non-bug for an hour.