Title: Self-hosted + Authentik: token validates fully (matching iss/aud/azp, valid signature), but users table stays at 0 rows — every /api/* call returns generic 401

Community Support Self-Hosted
1

Self-hosted NetBird + Authentik OIDC, both on the same Docker Compose stack behind Caddy (Cloudflare DNS + auto-HTTPS). netbirdio/management:latest, netbirdio/dashboard:latest — management server reports version 0.77.0.

Symptom: Login completes fully on Authentik’s side (/application/o/token/ → 200, /application/o/userinfo/ → 200). Dashboard briefly loads real content, then bounces back to Authentik’s consent screen in a loop. Every authenticated call to netbird-mgmt (e.g. GET /api/users) returns a flat 401 {"message":"no valid authentication provided","code":401} — no more specific reason at any log level, including --log-level debug.

Ruled out via direct token decode (browser console):

  • iss: https://authentik.the-bishop.com/application/o/netbird/ — matches HttpConfig.AuthIssuer exactly.
  • aud and azp: both match HttpConfig.AuthAudience and PKCEAuthorizationFlow.ProviderConfig.ClientID exactly.
  • Token is a valid ID token (auth_time, acr, amr, nonce, sid present) — UseIDToken: true is behaving as configured.
  • JWKS endpoint directly confirmed reachable, returns valid RS256 key with matching kid.
  • Authentik provider is Public/PKCE client type (fixed an earlier “Invalid client secret” issue by switching from Confidential).

The actual finding, which I think narrows this down significantly: queried store.db directly — SELECT count(*) FROM users returns 0, despite dozens of fully successful-looking logins over several hours. store.db’s file mtime hadn’t updated in 5+ days despite today’s extensive testing. Write permissions confirmed fine (touch test inside the container succeeds, process runs as root). This suggests the failure isn’t in JWT validation at all, but in the account/user auto-provisioning step that’s supposed to run after a valid token comes in (GetAccountIDFromUserAuth per the docs) — that step appears to be silently failing every time, and the generic 401 is what surfaces instead of a real error.

SingleAccountMode is enabled via --single-account-mode-domain flag. IdpManagerConfig is null (no IdP sync configured).

Happy to share full management.json (secrets redacted) or any further logs — what would help narrow down the provisioning-step failure specifically?