fix(authn): Google sign-in goes direct to Google + repair auth e2e drift from the Security API cutover

[izzywdev]

Two AuthN correctness fixes this session owns. Both stem from the Security API cutover.

1. Google sign-in got stuck on Authentik's UI

startSocialLogin 302'd to the generic OIDC authorize endpoint. Authorize requires a session; with none, Authentik falls back to the brand's auth flow and renders its identification page (/if/flow/...) with a "Google" button — the IdP's own UI, leaking across our boundary.

Fix: launch the Google source directly — /source/oauth/login/google/?next=<authorize>. That view 302s straight to accounts.google.com; after the callback the source flow runs (silent enrollment first time, login when returning), then next resumes authorize, which issues the code silently. Same cookie/state/PKCE round-trip — one hop inserted ahead of authorize, so no /if/flow/ ever renders. Adds a regression assertion that the redirect never matches /if/.

This unblocks devops dropping /if from the IdP ingress.

2. The auth e2e suite was testing endpoints we deleted

E2E (sign-in) has been red on master since the cutover — not flake, and not something to wave off as "pre-existing". The SPA moved to /api/v1/security/* (POST /session, GET /methods, /social/google/start, /session/exchange) but the tests still waited on /api/auth/login and mocked /api/auth/method. The frontend never calls those anymore, so waitForResponse hung until timeout.

Repointed: auth-simple, clock-load, mobile-layout, pages/login-page, google-signin, federated-apps-register-activate, and the post-prod live-smoke. Where login is awaited, the HTTP method is matched too — GET /session ("me") shares the URL and would otherwise satisfy the wait before login completed.

Also adds the coverage that was missing: oidc-plumbing only exercised the deprecated /api/auth shim and had zero coverage of the surface the SPA and consumers actually use. It now asserts the capability descriptor, password sign-in, wrong-password 401, and a boundary check that no response leaks authentik/permit. The shim assertions stay — it's still mounted for one release.

Verification

CI is the gate (local install hangs on this Windows box). The proof is E2E (sign-in) going green on this PR having been red on master.

hold + no auto-merge — master is deploy-on-push; merge in a deploy window. Does not touch package-lock.json.

Co-Authored-By: Claude

[github-actions]

Automated code review (gate-code-review)

• backend/security/src/providers/authentik/AuthentikIdentityProvider.ts:262 — The source path is hardcoded to /source/oauth/login/google/, ignoring the provider argument to startSocialLogin. Any non-Google social provider will now be silently routed through Google's source login instead of its own, breaking that flow (previously the redirect derived from the provider-specific url).

Report-only — this check never blocks merge.

[github-actions]

Automated code review (gate-code-review)

Credit balance is too low

Report-only — this check never blocks merge.

[github-actions]

Automated code review (gate-code-review)

Credit balance is too low

Report-only — this check never blocks merge.

[izzywdev]

Re: the gate-code-review note on AuthentikIdentityProvider.ts:262 (hardcoded /source/oauth/login/google/) — fixed in 2e2461e: the slug now tracks provider (/source/oauth/login/${provider}/).

One correction for the record: it wasn't a live break. startSocialLogin throws InvalidInputError for any provider !== google before reaching that line, so no other provider could ever be routed through Google's source. But the underlying point stands as a latent trap — widening that guard would have silently sent a new provider to Google. The slug and the guard can no longer drift apart.

(The second review comment reported only "Credit balance is too low" — no finding to address.)

🤖 Addressed by Claude Code

[izzywdev]

gate-code-review reported only "Credit balance is too low" — the reviewer bot failed to run rather than raising a finding, so there is nothing to address from it. (Its earlier substantive note, the hardcoded google source slug, was fixed in 2e2461e.)

The two red checks — Playwright sign-in flow and OIDC plumbing — are known and genuinely red, not flake. Root cause: the SPA now signs in via /api/v1/security/*, which only backend/security serves, and no e2e stack runs that service (docker-compose.e2e.yml builds the monolith backend/Dockerfile; e2e.yml starts the monolith only, with no Authentik). So the login POST 404s and the wait times out. Prod is unaffected — the k8s Ingress routes /api/v1/security → fuzefront-security.

Fix is in flight as separate PRs (add the security service to the compose stack + route it in nginx; then repoint the sign-in workflow). This PR stays red until that lands — deliberately not papering over it.

🤖 Addressed by Claude Code