Regression: Authentik SSO not working with 1.5.0-rc.21

[begunfx]

Drydock version

1.5.0-rc.21

What happened?

Just updated to rc.21 and it seems I cannot connect to Authentik to authenticate via SSO anymore. Had to use my fallback credentials to login. Only change I made to the compose file was the new option:
- DD_AGENT_ALLOW_INSECURE_SECRET=true

Seeing the following message in the drydock controller container log:

[09:09:14.401] DEBUG (drydock/7): Executing oidc strategy {"component":"authentication.oidc.authentik"}

[09:09:14.402] DEBUG (drydock/7): No bearer token provided {"component":"authentication.oidc.authentik"}

[09:09:14.403] DEBUG (drydock/7): Executing oidc strategy {"component":"authentication.oidc.authentik"}

[09:09:14.404] DEBUG (drydock/7): No bearer token provided {"component":"authentication.oidc.authentik"}

[09:09:14.406] DEBUG (drydock/7): Executing oidc strategy {"component":"authentication.oidc.authentik"}

[09:09:14.406] DEBUG (drydock/7): No bearer token provided {"component":"authentication.oidc.authentik"}

[09:09:16.307] DEBUG (drydock/7): Executing oidc strategy {"component":"authentication.oidc.authentik"}

[09:09:16.307] DEBUG (drydock/7): No bearer token provided {"component":"authentication.oidc.authentik"}

[09:09:16.314] DEBUG (drydock/7): Discovering configuration from https://auth.justthebeguns.com/application/o/drydock/.well-known/openid-configuration {"component":"authentication.oidc.authentik"}

[09:09:16.315] WARN (drydock/7): TLS certificate verification disabled for OIDC - do not use in production {"component":"authentication.oidc.authentik"}

[09:09:16.317] WARN (drydock/7): Unable to initialize OIDC session (fetch failed) {"component":"authentication.oidc.authentik"}

What did you expect?

see above

Steps to reproduce

See above

Relevant configuration

Logs

Installation method

Docker Compose

Docker version

24.0.1

OS / Architecture

Synology DSM 7

[s-b-e-n-s-o-n]

Thanks for the detailed log @begunfx — sorry you hit this.

Quick diagnosis blocker: the Unable to initialize OIDC session (fetch failed) line you're seeing is undici's generic surface error. The actual root-cause code (DNS, TLS, connection refused, certificate chain, etc.) lives on error.cause which we weren't logging. I just landed a fix on main (720d99a3) that walks the cause chain and prints e.g. fetch failed ← getaddrinfo ENOTFOUND auth.justthebeguns.com [ENOTFOUND] or fetch failed ← self signed certificate in certificate chain [UNABLE_TO_VERIFY_LEAF_SIGNATURE]. It'll be in the next RC.

While you wait, three things would help us pinpoint the regression:

1. Run this from inside the drydock controller container:

   docker exec -it <drydock-container> sh -c \
     'curl -kv https://auth.justthebeguns.com/application/o/drydock/.well-known/openid-configuration 2>&1 | head -30'

   If curl gets a response, the network/DNS/TLS path is fine and the regression is in Node's fetch (likely the undici 7→8 bump in rc.20). If curl errors too, it's a container-side reachability issue.

2. Confirm the version you upgraded from. The relevant deltas:

   • rc.20 (May 14) bumped undici 7.24.6 → 8.2.0
   • rc.21 (May 15) only touched the Dockerfile (Alpine curl unpin) and auth-session.ts (auto-persist DD_SESSION_SECRET), no OIDC code changes

3. One more sanity check — your env exports for OIDC, redacted as needed:

   docker exec <drydock-container> env | grep -E '^DD_AUTH_OIDC_AUTHENTIK_' | sed 's/SECRET=.*/SECRET=***/'

   In particular, is DD_AUTH_OIDC_AUTHENTIK_INSECURE=true set (the WARN suggests yes), and is DD_AUTH_OIDC_AUTHENTIK_CAFILE set?

The DD_AGENT_ALLOW_INSECURE_SECRET=true you added is unrelated — it only affects the agent-secret-over-HTTP guard in AgentClient, not OIDC.

Labelled area:security + needs-info; will gate the next RC cut on a confirmed root cause.

[begunfx]

I had upgraded from rc.19 -> to rc.21 due to the Agent Secret issue. OIDC was working without issue in rc.19.

I ran the curl command and got a successful response

Here's my OIDC environment variables:

- DD_PUBLIC_URL=https://<redacted>
      - DD_AUTH_OIDC_AUTHENTIK_CLIENTID=<redacted>
      - DD_AUTH_OIDC_AUTHENTIK_CLIENTSECRET=<redacted>
      - DD_AUTH_OIDC_AUTHENTIK_DISCOVERY=https://<redacted>/application/o/drydock/.well-known/openid-configuration
      - DD_AUTH_OIDC_AUTHENTIK_INSECURE=true #for self-signed certificates use this to skip TLS verification for OIDC
      - DD_AUTH_OIDC_AUTHENTIK_REDIRECT=false # optional (to skip internal login page)

[s-b-e-n-s-o-n]

Confirmed root cause, fix on main (03ed0f4a). It's an undici cross-version dispatcher mismatch:

• Node 24 ships built-in undici 7.21.0 (v1 dispatcher interface).
• rc.20 bumped the userland app's undici 7.24.6 → 8.2.0 (v2 dispatcher interface, e763e09f).
• The OIDC code constructed an Agent from userland undici 8 and passed it as dispatcher to Node's global fetch — which is bound to built-in undici 7. The v2 Agent's handlers don't satisfy the v1 contract → TypeError: fetch failed, no underlying cause exposed.
• This is exactly what nodejs/undici#4827 calls out. On Node 22 there's a Dispatcher1Wrapper bridge; on Node 24 there isn't, so the combo silently fails.

The path was only triggered when a custom dispatcher was needed — i.e., when DD_AUTH_OIDC_*_INSECURE=true or DD_AUTH_OIDC_*_CAFILE=... was set. Anyone running with a public CA-signed IdP wouldn't have hit this; that's why it slipped past pre-release testing despite landing in rc.20.

Fix: one-line — import fetch from undici and use it in the custom-dispatcher branch so both halves share the same dispatcher version. The default fetch path (no cafile/insecure) is unchanged.

Will go out in rc.22. Thanks for the crisp repro — confirmed your curl-works output plus the env dump narrowed this down inside an hour.

[begunfx]

Authentik SSO working again in rc.22. Thanks! Feel free to close.