auth.uid() Returns Null After Rotating Supabase JWT Keys

Your user is logged in. The session is valid, the access token is in the Authorization header, and supabase.auth.getUser() cheerfully returns their profile. Then every insert fails with new row violates row-level security policy, Postgres error 42501, and updates quietly change zero rows without raising anything at all.

If that started right after you clicked "Rotate keys" in the Supabase dashboard, this page is for you. There's a fix that makes it all go away in about four seconds, and it's the worst thing you could do.

The Four-Second Fix That Publishes Your Database

Here is the exact sequence, taken from a developer in Supabase discussion #45812 on 2026-05-12. They rotated from the legacy HS256 secret to ECC P-256, authenticated inserts started failing with 42501, and they tried the obvious thing:

Disabling RLS on the table allows inserts to succeed.

It does. It always will. And on a Supabase project, Row Level Security is not a nice-to-have layer on top of a private database. It is the entire access control model. Your publishable key (formerly the anon key) is designed to sit in your frontend where anyone can read it, and the only thing standing between that key and every row in a table is the policies on that table.

We scan for exactly this end state: tables reachable with the publishable key that return rows they shouldn't. The finding looks identical whether RLS was never enabled or was switched off during a bad afternoon. If you've already done this to restore service, turn RLS back on and roll back the key change instead. A broken login is an outage. A public users table is a disclosure.

First, Check Whether You Needed to Rotate at All

This is the part that gets skipped, and it's the one that would have prevented most of these incidents.

Supabase is running two separate migrations, and people are conflating them:

The announcement post is unambiguous about the first one:

You're not required to change your JWT secret unless you choose to.

And the signing keys documentation says that if you aren't ready, "you can stop here without any issue."

So the failure pattern goes like this. A founder reads that their Supabase keys are being retired by late 2026, which is true of the API keys. They open Project Settings, see a "Migrate JWT secret" button sitting right there, assume it's the same deadline, and click it. Two migrations, one dashboard, one panic. Only one of them was due.

There are real reasons to move to asymmetric keys, mainly that your services can verify tokens locally against a public key instead of calling the Auth server. It's a genuine improvement. It just isn't urgent, and it shouldn't be done in the same sitting as a deadline you misread.

What the Reports Actually Say

Being precise here matters, because the honest version of this story is narrower than the alarming version.

Since May 2026, at least three distinct GitHub accounts have filed reports describing the same shape of failure on hosted Supabase projects after migrating to asymmetric signing keys:

• Issue #47621 (2026-07-05) is the clearest statement of it: "authenticated requests resolve as anon, auth.uid() is NULL, RLS 42501 on INSERT," with UPDATEs silently affecting no rows while GoTrue accepts the very same token. The reporter says they reproduced it with both ES256 and a freshly rotated RS256 key, and wonders whether the verifier is still pinned to the legacy HS256 secret rather than consulting the project's JWKS. That's their hypothesis, not a confirmed cause.
• Issue #48341 (2026-07-27) reports auth.uid() returning null despite a valid session, with auth.uid() working correctly when the claims are supplied manually.
• Issue #48116 (2026-07-20) is a Storage upload rejected by RLS with a valid ES256 token. Worth listing, but it's the Storage enforcement path rather than the Data API, so it isn't quite the same bug.

Now the caveats, because they change what you should conclude.

All three issues were closed on the same day they were opened, and all three still carry a to-triage label. There is no public Supabase maintainer diagnosis of any of them, no status-page incident, and no changelog entry acknowledging a Data API verification problem. A closed issue with a triage label is not a fixed issue, but it isn't a confirmed platform bug either.

One nearby case did get a maintainer response, and it's a different symptom. In discussion #48246 (2026-07-23), five people reported intermittent bad_jwt: unrecognized JWT kid for algorithm ES256 errors on Auth Admin API calls. A Supabase maintainer replied "Should be fixed. Apologies!" on 2026-07-25, and a reporter confirmed two clean runs of fifty requests afterward. No cause was stated publicly. A cache-desynchronisation explanation circulating in that thread came from a community member who explicitly noted they had no access to Supabase's internal infrastructure, so treat it as a guess.

Most recently, discussion #48902 (2026-08-10) describes GoTrue issuing an ES256 token and then returning 401 for that same token. It has community replies and no maintainer resolution as of 2026-08-12.

One documented cause does exist, and it's worth ruling out first if it applies to you: on self-hosted Supabase, every service that verifies tokens (PostgREST, Realtime, Storage) must be configured with JWT_JWKS. Miss that and you get precisely these symptoms. It doesn't explain the hosted reports above, which cite project refs, but if you self-host, start there.

Diagnose It Before You Change Anything

The reason this gets misdiagnosed is that it presents as an authorization failure and begins as an authentication one. Your policies are probably fine. Work outward from the token.

const { data: { session } } = await supabase.auth.getSession()
const [header, payload] = session.access_token
  .split('.')
  .slice(0, 2)
  .map(part => JSON.parse(atob(part.replace(/-/g, '+').replace(/_/g, '/'))))

console.log(header)   // { alg: "ES256", kid: "...", typ: "JWT" }
console.log(payload)  // { sub: "...", role: "authenticated", exp: ... }

curl -s "https://<PROJECT_REF>.supabase.co/auth/v1/.well-known/jwks.json" \
  | grep -o '"kid":"[^"]*"'

create or replace function public.whoami()
returns json
language sql
security invoker
as $$
  select json_build_object(
    'uid', auth.uid(),
    'role', auth.role(),
    'claims', current_setting('request.jwt.claims', true)
  );
$$;

const { data } = await supabase.rpc('whoami')
console.log(data)

Rotate Safely, When You Choose To

If you do want asymmetric keys, the sequence and the waiting are the whole job. From the signing keys documentation:

• The JWKS discovery endpoint is cached by Supabase's edge servers for 10 minutes.
• Supabase client libraries may cache keys in memory for another 10 minutes.
• The multi-level cache "is cleared every 20 minutes, or longer if you have a custom setup."

So a freshly rotated key can be genuinely correct and still be rejected by something that hasn't caught up. Rotating twice in quick succession, which is what a panicking person does, makes that worse rather than better.

The revoke step has its own rule, quoted directly:

If your access token expiry time is configured to be 1 hour, wait at least 1 hour and 15 minutes before revoking the legacy JWT secret.

Revoking early invalidates tokens that are still in real users' browsers. They get logged out, some of them retry, and now you're debugging two problems at once.

A sane order looks like this. Rotate on a staging project first and leave it for a day. On production, rotate during low traffic, then immediately run the step 3 whoami check with a real user's token before you touch anything else. If uid comes back null, roll back to the legacy key while it's still available rather than pushing forward. Only revoke the legacy secret after the expiry window has fully passed and you've confirmed real logins work.

If You Already Disabled RLS

Fix that first, before you resume debugging the key.

-- Find every table in your public schema without RLS enabled
select tablename
from pg_tables
where schemaname = 'public'
  and tablename not in (
    select tablename from pg_tables t
    join pg_class c on c.relname = t.tablename
    where c.relrowsecurity = true and t.schemaname = 'public'
  );

Re-enable it, confirm the policies you had are still there (disabling RLS doesn't drop policies, so they should be intact), and treat any data that was reachable in the meantime as potentially read. How long the window was open matters more than how obscure your project URL is. Your project ref and publishable key are in your frontend bundle, which means they're in anyone's browser cache and possibly in a search engine's.