State on master 215bd6a
OIDC Plumbing E2E is 7 passing / 3 failing — a real improvement (it was fully red). Everything API-level is green, including the boundary assertion:
✓ Authentik OIDC discovery document is reachable and well-formed
✓ backend reports oidcConfigured:true (deprecated /api/auth shim)
✓ Security API advertises neutral capabilities incl. Google social
✓ Security API password sign-in returns a platform JWT session
✓ Security API rejects a wrong password with 401
✓ password sign-in against Authentik (no redirect) returns a platform JWT
✓ password sign-in rejects a wrong password with 401
✘ full OIDC sign-in flow with local user lands on dashboard with a real JWT
✘ native email/password form signs in via Authentik and lands on dashboard
✘ OIDC error from Authentik is displayed on the login page
Why the 3 fail — they encode the flow we deliberately removed
waiting for navigation to "http://authentik-server:9000/**" → Timeout 25000ms
Two independent causes, both by design:
1. The boundary keeps the browser on the app origin. waitForURL(${AUTHENTIK_URL}/**) asserts the browser navigates to the IdP host. It no longer does, and must not — nginx proxies Authentik's native paths under the app origin. The assertion is now backwards: navigating to authentik-server:9000 would be a boundary breach, not success.
2. The test used the Google button as a shortcut to Authentik's login page. Its own comment says it:
"This e2e Authentik has no Google source, so the button lands on Authentik's own identification flow — exactly what we want to drive."
The google-direct fix (#277) deleted exactly that hop: the button now launches /source/oauth/login/google/, and this e2e stack has no Google source configured, so there is nothing to land on. The test depended on the bug.
This is the same class as the @gdemo test, which I already repointed at the direct-to-Google flow.
Suggested rework (not a URL swap — the premise changed)
full OIDC sign-in flow: stop using the Google button as a proxy for the IdP login page. Either drive the native credentials form (that is what the SPA actually offers), or configure a Google source in the e2e Authentik if the redirect leg is what we want covered.- Replace
waitForURL(AUTHENTIK_URL/**) with the inverse assertion: the browser must stay on the app origin, and auth.fuzefront.com / the IdP host must never appear. That turns a stale assertion into the boundary regression test.
native email/password form and OIDC error … displayed: verify against the current login page; both fail downstream of the same navigation assumption.
Why this matters beyond the red
Playwright sign-in flow (e2e.yml) is permanently red by construction (monolith, no Authentik, bcrypt-seeded account — /api/v1/security/session → 404) and should be retired; it cannot be repaired in place. Once these 3 are reworked, OIDC Plumbing is the one honest auth e2e and is worth making a required check — today neither auth e2e is required (only the gate-* contexts are), which is precisely how a broken sign-in path stayed red for days and three bot-authored bcrypt shims nearly papered over it.
Related: #286 (required-check deadlock), #283 (fixed in #284).
State on master
215bd6aOIDC Plumbing E2Eis 7 passing / 3 failing — a real improvement (it was fully red). Everything API-level is green, including the boundary assertion:Why the 3 fail — they encode the flow we deliberately removed
Two independent causes, both by design:
1. The boundary keeps the browser on the app origin.
waitForURL(${AUTHENTIK_URL}/**)asserts the browser navigates to the IdP host. It no longer does, and must not — nginx proxies Authentik's native paths under the app origin. The assertion is now backwards: navigating toauthentik-server:9000would be a boundary breach, not success.2. The test used the Google button as a shortcut to Authentik's login page. Its own comment says it:
The google-direct fix (#277) deleted exactly that hop: the button now launches
/source/oauth/login/google/, and this e2e stack has no Google source configured, so there is nothing to land on. The test depended on the bug.This is the same class as the
@gdemotest, which I already repointed at the direct-to-Google flow.Suggested rework (not a URL swap — the premise changed)
full OIDC sign-in flow: stop using the Google button as a proxy for the IdP login page. Either drive the native credentials form (that is what the SPA actually offers), or configure a Google source in the e2e Authentik if the redirect leg is what we want covered.waitForURL(AUTHENTIK_URL/**)with the inverse assertion: the browser must stay on the app origin, andauth.fuzefront.com/ the IdP host must never appear. That turns a stale assertion into the boundary regression test.native email/password formandOIDC error … displayed: verify against the current login page; both fail downstream of the same navigation assumption.Why this matters beyond the red
Playwright sign-in flow(e2e.yml) is permanently red by construction (monolith, no Authentik, bcrypt-seeded account —/api/v1/security/session→ 404) and should be retired; it cannot be repaired in place. Once these 3 are reworked,OIDC Plumbingis the one honest auth e2e and is worth making a required check — today neither auth e2e is required (only thegate-*contexts are), which is precisely how a broken sign-in path stayed red for days and three bot-authored bcrypt shims nearly papered over it.Related: #286 (required-check deadlock), #283 (fixed in #284).