feat: surface Google SSO on the login page

[geekypunk]

Problem

Google Workspace SSO is fully implemented server-side but unreachable from the UI.

Present and working:

• GET /auth/google/start and /auth/google/callback (AuthController)
• both permitAll in SecurityConfig
• PasswordlessAuthService.isAllowedWorkspaceDomain() gates on the google_workspace_domain allowlist and a matching OIDC hd claim
• authAPI.getGoogleStartUrl() in src/lib/api/client.js

Nothing ever calls that helper. Login.jsx contained no Google reference at all, so on an install with SECURITY_GOOGLE_ENABLED=true the only way to use SSO was typing /api/auth/google/start into the address bar.

Why extend /setup/status instead of adding an endpoint

The login page is unauthenticated, so it cannot read security.google.enabled to decide whether to render the button. GET /setup/status is already public and already fetched by Login.jsx on mount, so the flag rides along at no extra request and no new surface area.

Installs that never configured Google get googleEnabled: false and render exactly as before.

Changes

SetupController — expose googleEnabled on the public status response.

The field is deliberately not final: @RequiredArgsConstructor would pull a final field into the generated constructor, and Spring has no bean to satisfy a boolean. Field injection via @Value is required here.

Login.jsx — render "Sign in with Google" below the password form when the flag is set.

It is a plain <a>, not a <button>: /api/auth/google/start responds 302 to Google, so this is a full-page navigation and must not submit the password form it sits under. Styling follows the existing form (white/bordered against the dark primary), with an "or" divider.

Testing

Verified on a live self-host install (backend 8.4 stack, SECURITY_GOOGLE_ENABLED=true, Workspace domain allowlisted):

• GET /api/setup/status → {"setupComplete":true,...,"googleEnabled":true}
• button renders on /login and navigates to accounts.google.com
• the redirect carries scope=openid email profile, PKCE code_challenge (S256), and a CSRF state
• with the flag unset, no button renders and the page is byte-identical to before

Note for maintainers

The dead getGoogleStartUrl() helper suggests this was started and never finished. Worth confirming there wasn't a different intended UX (e.g. SSO-only mode hiding the password form) — happy to adjust.

Related: security.password.enabled does not exist, so enabling SSO does not disable password login. Any deployment relying on SSO as an exclusive gate still has /auth/login open to existing local accounts. Not addressed here, but worth flagging.

[geekypunk]

Added a second commit: security.password.enabled, so SSO can actually be exclusive.

The original PR note flagged that enabling Google does not close /auth/login. This implements the missing toggle rather than leaving it as a caveat.

loginWithPassword() never consulted security.google.enabled, /auth/login is permitAll unconditionally, and no flag existed — so a deployment fronting DeepSQL with Google Workspace still had every local account reachable by password. The new flag defaults to true, so existing installs are unaffected.

Notable details:

• The check sits before the rate limiter and before any credential comparison. Nothing needs rate-limiting when the path is closed, and rejecting early avoids leaking whether an account exists.
• Refusals emit PASSWORD_LOGIN_FAILURE with reason=password_login_disabled, so turning it on is auditable rather than silent.
• A @PostConstruct guard logs an ERROR when password and Google are both disabled — that combination locks everyone out and is otherwise only discovered at the login screen.
• The frontend guard is passwordLoginEnabled !== false, not a truthiness test. setupStatus is null on first paint and the field is undefined on installs predating the flag; both must render the form. Inverting that would strand users on a login page with no way in whenever the status call was slow or failed.

Verified on the same live self-host install, with SECURITY_PASSWORD_ENABLED=false:

/api/setup/status  -> "googleEnabled":true,"passwordLoginEnabled":false
POST /api/auth/login (real admin, valid account)
                   -> {"message":"Password sign-in is disabled. Please sign in with Google."}
/api/auth/google/start -> 302 (unaffected)
startup log        -> Password sign-in is DISABLED (security.password.enabled=false); Google SSO only.
security_event     -> PASSWORD_LOGIN_FAILURE | {"reason": "password_login_disabled"}

Login page renders the Google button alone — no password fields, no orphaned "or" divider. With the flag unset, the page is unchanged.