HELP: admin.generateLink / admin.getUserById fail with "unrecognized JWT kid" after JWT Signing Keys migration — blocks Auth Admin API entirely

[reliasam]

Hi everyone!

After migrating to the new JWT Signing Keys (ES256), I've run into an issue where admin.generateLink() and admin.getUserById() consistently fail with:
AuthApiError: invalid JWT: unable to parse or verify signature, token is unverifiable: error while executing keyfunc: unrecognized JWT kid for algorithm ES256
A few details in case they help narrow it down:

• Called from an Edge Function using the service role / secret key (sb_secret_... format)
• @supabase/supabase-js@2, on the latest published version
• Happens on every call, not intermittent
  Things I've already tried without luck: redeploying the function, double-checking I'm using the new secret key format (not a stale legacy one), and confirming the client library is up to date.
  This is blocking part of our auth flow (using generateLink + verifyOtp to mint a session for a known user id server-side), so I'd really appreciate any pointers. I did open a support ticket (SU-431303), but totally understand free-plan tickets don't have a guaranteed SLA, so thought I'd also ask here in case someone's run into the same thing after migrating to ES256, or knows whether falling back to the legacy JWT secret is still possible as a temporary workaround.

Thanks so much for any help!

[farfromexact]

The important distinction here is that sb_secret_... is an opaque API secret, not a JWT. The legacy service_role key is a JWT. That matches the symptom: the Auth Admin path is trying to verify a JWT and reports kid <nil>, while an opaque key does not carry JWT header fields such as kid.

Supabase documents both the new signing-key model and the two API-key types here:

• https://supabase.com/docs/guides/auth/signing-keys
• https://supabase.com/docs/guides/getting-started/api-keys

As a temporary backend-only workaround, if the legacy key is still available, create the admin client with the legacy service-role JWT rather than the sb_secret_... key:

const supabase = createClient(
  Deno.env.get('SUPABASE_URL')!,
  Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  { auth: { autoRefreshToken: false, persistSession: false } }
)

Keep that key only in Edge Function secrets; do not put it in browser code, return it to clients, or log it. This should let you verify whether the failure is specifically the new-key/Auth Admin compatibility path while the support ticket is investigated. If the legacy secret has been removed, I would not mint a custom JWT as a workaround; the safer next step is to ask Supabase to confirm support for generateLink and getUserById with sb_secret_... after ES256 migration and provide the project/library versions without sharing any secret value.

[reliasam]

This is really helpful, thank you.

The "opaque key vs JWT" framing makes a lot of sense and matches the error message perfectly — kid is exactly what you'd get from trying to read a JWT header off a token that was never a JWT to begin with.

I ended up going with a slightly different flavor of the same idea: instead of switching back to the legacy service_role key, I rewrote the admin calls (generateLink / getUserById) to hit the REST endpoints directly with fetch(), using the sb_secret_... key as-is. Deployed it and the flow that was broken is working again. Your explanation is honestly the first thing that made the "why" click for me instead of just having a workaround that happened to work.

Still chasing a separate failure in another function that doesn't touch admin.* at all (just getUser() + .rpc()), so this isn't fully closed on my end, but this piece of the puzzle is solved.

Appreciate you taking the time to write this out!

[farfromexact]

no problem :D