Migrate the local + E2E authentik harness to 2026.5.5 (needs a security-service flow-driver update)
Split out of #555 / PR #556.
PR #556 rolls the prod Helm chart forward to authentik 2026.5.5 (the load-bearing fix for the wedged rollout). It intentionally leaves docker-compose.yml and docker-compose.e2e.yml on 2024.12.3 because bumping them broke CI:
OIDC Plumbing E2E and E2E (sign-in) fail on 2026.5.5 (both pass on master @ 2024.12.3).- Provisioning (
deploy/e2e/provision-authentik-oidc.sh) succeeds — implicit-consent authorization flow resolves, OAuth2 provider + invalidation flow are created.
- At sign-in the security service logs:
Unsupported Authentik flow stage: authorize returned HTTP 200 without redirect (consent flow?) (only identification+password is supported server-side) -> Authentik rejected credentials -> POST /api/v1/security/session -> 503.
Root cause
authentik 2026.5.5's server-side flow executor returns the final redirect as an HTTP 200 challenge ({"type":"redirect","to":"...?code=..."}) instead of an HTTP 302 with a Location header. The security service's headless OIDC flow driver (the POST /oidc/password path used for the same-origin POST /api/v1/security/session sign-in) only handles identification+password and treats an HTTP-200 authorize response as an unsupported consent flow.
Work required
- Update the security-service headless flow driver to handle authentik's
redirect challenge type (extract the to URL / code from the 200 JSON body) in addition to HTTP 302.
- Bump
docker-compose.yml + docker-compose.e2e.yml to ghcr.io/goauthentik/server:2026.5.5 and update the 2024.12.3 comments in deploy/e2e/provision-authentik-oidc.sh.
- Confirm
OIDC Plumbing E2E and E2E (sign-in) are green on 2026.5.5.
Why it's safe to defer
Prod already runs 2026.5.5 and interactive browser OIDC works there; only the headless/same-origin password-exchange path exercised by the E2E harness is affected. Local dev that uses the same headless path will hit the same 503 until this lands.
Migrate the local + E2E authentik harness to 2026.5.5 (needs a security-service flow-driver update)
Split out of #555 / PR #556.
PR #556 rolls the prod Helm chart forward to authentik
2026.5.5(the load-bearing fix for the wedged rollout). It intentionally leavesdocker-compose.ymlanddocker-compose.e2e.ymlon2024.12.3because bumping them broke CI:OIDC Plumbing E2EandE2E (sign-in)fail on2026.5.5(both pass on master @2024.12.3).deploy/e2e/provision-authentik-oidc.sh) succeeds — implicit-consent authorization flow resolves, OAuth2 provider + invalidation flow are created.Unsupported Authentik flow stage: authorize returned HTTP 200 without redirect (consent flow?) (only identification+password is supported server-side)->Authentik rejected credentials->POST /api/v1/security/session -> 503.Root cause
authentik
2026.5.5's server-side flow executor returns the final redirect as an HTTP 200 challenge ({"type":"redirect","to":"...?code=..."}) instead of an HTTP 302 with aLocationheader. The security service's headless OIDC flow driver (thePOST /oidc/passwordpath used for the same-originPOST /api/v1/security/sessionsign-in) only handles identification+password and treats an HTTP-200 authorize response as an unsupported consent flow.Work required
redirectchallenge type (extract thetoURL /codefrom the 200 JSON body) in addition to HTTP 302.docker-compose.yml+docker-compose.e2e.ymltoghcr.io/goauthentik/server:2026.5.5and update the2024.12.3comments indeploy/e2e/provision-authentik-oidc.sh.OIDC Plumbing E2EandE2E (sign-in)are green on2026.5.5.Why it's safe to defer
Prod already runs
2026.5.5and interactive browser OIDC works there; only the headless/same-origin password-exchange path exercised by the E2E harness is affected. Local dev that uses the same headless path will hit the same 503 until this lands.