Intermittent 403 "unrecognized JWT kid <nil> for algorithm ES256" on Admin API with valid sb_secret key

[richardhrdlicka]

Since 2026-07-22, GET /auth/v1/admin/users/{id} on our hosted project intermittently returns 403 with:

invalid JWT: unable to parse or verify signature, token is unverifiable: error while executing keyfunc: unrecognized JWT kid <nil> for algorithm ES256

Environment

• Hosted Supabase project, ref btvisumxjqcpawtflxvh (eu-central), Auth version 2.193.1 (latest, per Infrastructure page)
• Authorization: our sb_secret_… API key (not a JWT), sent via supabase-py (auth.admin.get_user_by_id)

Symptoms

• ~1 in 6 calls fails; identical consecutive requests from a single process (same key, same target user, 1 s apart) yield mixed results, e.g. OK/OK/OK/FAIL/OK/OK.
• Failures occur at all hours; first occurrence 2026-07-22, frequency increasing (on 2026-07-25 we saw 2 failures within 40 seconds: 08:35:02 and 08:35:36 UTC; also 08:05:02 UTC).
• Onset coincides with the rollout window of Auth v2.193.1 / the v2.194.0 RCs (2026-07-22).

Config is clean and long-settled

• Current signing key: ECC (P-256) with a proper kid; no standby key; no previously-used keys
• Legacy HS256 shared secret: revoked ~4 months ago
• No key or settings changes on our side in months

Why we believe this is platform-side
Our sb_secret_… key is not a JWT at all, so the ES256 token the keyfunc rejects cannot be the credential we sent — it appears to be minted inside the platform (gateway → auth exchange), and some replica/path signs or resolves it without a kid.

Happy to provide more timestamps or run diagnostics.

[webhesapkontrol-ctrl]

Independent corroboration from a second project — same signature, different call surface.

Environment

• Hosted project ref lqkvgykgxmplzkeuwnhi, region eu-central-1 (same region as the reporter's project)
• Auth calls made via supabase-js admin API from a test harness (service role)
• Credential: sb_secret_… (not a JWT). Legacy anon/service_role JWT keys disabled and the legacy HS256 secret revoked on 2026-07-24 — the failures continued unchanged afterwards, so this is not legacy-key propagation
• Single current signing key: ECC (P-256), no standby key, no config changes on our side
• No Edge Functions

Measurement — 8 consecutive harness runs on 2026-07-25
Instrumented a wrapper that catches only the exact unrecognized JWT kid <nil> for algorithm ES256 signature and counts every occurrence. Totals across the 8 runs:

Admin call	Failures
deleteUser	8
createUser	5
generateLink	3
listUsers	0
Total	16

• Error string is byte-identical across all 16 occurrences.
• Transient in every case: a single bounded retry cleared it (worst case 2 of 3 attempts). No call ever failed permanently.
• First occurrence recorded in our logs on 2026-07-23, which is consistent with the 2026-07-22 onset reported above.

Note on the read/write question
The listUsers zero is an absence in this sample, not evidence of immunity — and since the failing call in the original report is a read (get_user_by_id), there does not appear to be a clean read-vs-write split. The failure looks indifferent to which admin method is invoked.

Happy to provide raw timestamps or run additional instrumented series if that helps narrow it down.