GoTrue returns 401 (no_authorization) for freshly-issued ES256 tokens — project-specific bug after JWT key rotation

[alcidessf]

Describe the bug

After rotating JWT signing from Legacy HS256 to ECC P-256, the /auth/v1/user endpoint returns HTTP 401 for every access token — including tokens freshly issued seconds earlier by GoTrue itself.

Project ref: foantlwwnlvobhzdnhnq
Auth version: 2.195.0
supabase-js: 2.108.2

What happens:

User logs in → GoTrue issues an ES256 token (verified via JWT header decode: alg=ES256, kid=1eebd6c2)
Token has valid sub, role=authenticated, 1 hour until expiry
Immediately calling GET /auth/v1/user with that token → HTTP 401
PostgREST receives all authenticated requests as role=anon, sub=null, auth_uid=null
JWKS endpoint (/auth/v1/.well-known/jwks.json) correctly shows both current and previous ECC keys
What was tried (no effect):

Project restart (before key rotation)
Created new standby ECC key → promoted to current (1eebd6c2)
Project restart (after key rotation)
Tested on web and native apps, multiple browsers, fresh sessions
Auth log entry for the 401:

{
"error": "401: This endpoint requires a valid Bearer token",
"error_code": "no_authorization",
"path": "/user",
"status": 401
}
Raw fetch test (both fail identically):

GET /auth/v1/user
apikey: <anon_key>
Authorization: Bearer <ES256 token, kid=1eebd6c2, exp +1h>
→ HTTP 401
JWKS response (correct, shows both keys):

{"keys":[
{"alg":"ES256","kid":"2ec96aac-...","kty":"EC"},
{"alg":"ES256","kid":"1eebd6c2-...","kty":"EC"}
]}
GoTrue issues tokens with kid=1eebd6c2 but cannot verify them. The issue appears to be in GoTrue's internal key verification state for this specific project.

[AasthaPJoshi]

This looks more like a verification-state/configuration divergence after the signing-key rotation than a malformed client token, especially because GoTrue itself is issuing the ES256 token and then /auth/v1/user immediately rejects it.

I would isolate this in three steps before concluding that the project is in a bad internal state.

1. Verify the freshly issued token independently against the project JWKS

Since the token header contains:

alg = ES256
kid = 1eebd6c2...

and the same kid is present at:

/auth/v1/.well-known/jwks.json

verify that exact JWT locally using the matching JWK.

If local verification succeeds, that establishes:

issued token signature
        +
published JWKS
        =
cryptographically consistent

That would make a client-side token-generation problem much less likely.

I would also check the usual claims while doing this:

iss
aud
sub
role
iat
exp
kid
alg

particularly that iss matches the project Auth issuer exactly.

2. Determine whether /auth/v1/user is failing before or after signature verification

The important symptom here is:

401
error_code = no_authorization
"This endpoint requires a valid Bearer token"

If the Authorization header is definitely reaching Auth unchanged, then I would expect the next useful diagnostic to be the underlying JWT verification error, not just the public no_authorization response.

For example, I would look for an internal error along the lines of:

unknown/unrecognized kid
signature verification failed
unexpected signing method
invalid issuer/audience

around the same request timestamp.

That distinction matters because:

Bearer header not reaching Auth

and

Bearer header reaches Auth but Auth cannot resolve/verify the ES256 key

can produce very similar external behavior while having completely different causes.

3. Compare Auth's effective verification key set with the public JWKS

The public JWKS showing the new key proves that the discovery endpoint knows about it.

It does not necessarily prove that every internal verifier/replica handling /user is operating from the same effective key state.

So the key invariant I would test is:

key used to sign token
        ==
key resolvable by verifier handling /auth/v1/user

not only:

key appears in public JWKS

Given that:

• fresh sessions are affected
• multiple clients reproduce it
• a project restart did not fix it
• rotating/promoting another ECC key did not fix it
• the current kid is visible in JWKS
• GoTrue itself issues the token immediately before rejecting it

I agree that this is difficult to explain as stale client state.

It looks more consistent with either:

1. Auth verification state not matching signing state for this project, or
2. a gateway/Auth path resolving a different/stale key configuration.

There is also a broader reason to look at key propagation carefully during asymmetric-key migration: Supabase's signing-key model depends on the JWKS being available to token verifiers, and key rotation introduces multiple simultaneously trusted keys during the transition.

One additional test that would make this report much stronger for a maintainer:

# 1. Obtain a brand-new access token

# 2. Decode its header and record:
alg
kid

# 3. Fetch JWKS and verify the same kid exists

# 4. Verify the JWT locally against that JWK

# 5. Immediately call:
GET /auth/v1/user
Authorization: Bearer <same-token>

# 6. Record all timestamps/request IDs

If step 4 succeeds while step 5 returns no_authorization, with the same untouched token, then you have a very clean boundary:

ES256 signing + public JWKS verification = valid
                    ↓
Supabase Auth /user verification path = rejects

At that point I would treat this as strong evidence of a project-side Auth verification-state issue rather than an application integration issue.

I would avoid rotating more keys for now, because additional rotations can make the state harder to reason about. Preserve the failing token, its kid, the corresponding JWKS response, and request timestamps so a maintainer can trace exactly which verifier handled the request.