Authenticated requests rejected by RLS as if unauthenticated — possibly related to recent JWT signing key rotation

[thedanielowolabi]

After my project's JWT signing key rotated from Legacy HS256 to ECC (P-256)
(shown in Settings → JWT Keys as rotated ~5 hours before this issue started),
authenticated REST requests to PostgREST are being rejected by Row Level
Security as if no user is logged in — even though the same session token is
confirmed valid by the Auth service.

Steps to reproduce:

1. A user signs up or logs in via supabase-js (sb.auth.signUp / signInWithPassword).
2. Calling sb.auth.getUser() with the resulting session succeeds and returns
   the correct user id with no error — confirming the access token is valid.
3. Calling sb.from('').insert(...) or any other authenticated
   PostgREST request using the same session is rejected with:
   {"code":"42501","message":"new row violates row-level security policy
   for table ..."}

Isolation steps already taken:

• Confirmed via pg_policies that the relevant RLS policies exist exactly
  as intended.
• Ran a direct SQL test in the SQL Editor, wrapped in BEGIN/COMMIT, using
  set local role authenticated; and set local request.jwt.claims = '...'
  with the real user's UUID — select auth.uid() correctly returned that
  user's id, and current_user correctly showed authenticated.
• Despite that, replacing the relevant policy with the simplest possible
  permissive rule — for insert to authenticated with check (true) — STILL
  results in the same rejection from the live application (not the SQL
  editor), strongly suggesting that real PostgREST requests from the
  deployed app are not being recognized as the authenticated role at all,
  even though the same token verifies successfully via the Auth service.
• Restarted the project (Settings → General → Restart project). No change.

This strongly suggests PostgREST/Data API is not correctly validating or
recognizing JWTs signed with the new ECC (P-256) key, possibly due to a
caching or propagation issue following the automatic key rotation.

Could you please check whether the Data API / PostgREST service for this
project is correctly synced to the current JWT signing key? Happy to
provide further logs or a minimal repro if useful.

[krotname]

The useful next split is: is PostgREST receiving the user JWT at all, or is it receiving it and failing to trust the new signing key?

Supabase's JWT docs say the Data API uses the JWT from Authorization: Bearer <jwt> and the role claim is the Postgres role used for RLS. So if for insert to authenticated with check (true) still fails, the live request is almost certainly not running as authenticated.

I would add a temporary debug RPC and call it from the same deployed app/client that fails:

create or replace function public.debug_request_jwt()
returns jsonb
language sql
stable
as $$
  select jsonb_build_object(
    'current_user', current_user,
    'role_claim', current_setting('request.jwt.claim.role', true),
    'sub_claim', current_setting('request.jwt.claim.sub', true),
    'auth_uid', auth.uid()
  );
$$;

grant execute on function public.debug_request_jwt() to anon, authenticated;

Then:

const { data, error } = await supabase.rpc('debug_request_jwt')
console.log({ data, error })

Interpretation:

• If it returns current_user: "authenticated", role_claim: "authenticated", and the expected auth_uid, then PostgREST is validating the token and the remaining issue is table/policy/insert shape.
• If it returns anon / null claims, inspect the actual failing REST request in the browser/network logs. It must include Authorization: Bearer <session.access_token>. auth.getUser() succeeding only proves the Auth client can validate the token; it does not prove that the PostgREST request is sending that token.
• If the failing REST request does include the ES256 token, the JWT payload has role: "authenticated", and the RPC still returns anon / null claims, then this looks like a Supabase platform/JWKS sync issue for that project and should go to support with the project ref, token kid, request id, and the RPC result.

One thing also worth trying after rotation is forcing a fresh access token / session refresh or signing out/in. The signing-keys docs say rotation causes Auth to issue new JWT access tokens immediately, while old non-expired tokens should remain accepted; if that contract is broken, the RPC above should make it visible.

Docs references:

• https://supabase.com/docs/guides/auth/jwts
• https://supabase.com/docs/guides/auth/signing-keys

[GaryAustin1]

If you look in the Gateway API log you should be able to see what the user role is in the detail data as decoded from the JWT.
I would think if JWT is being rejected you would get a different error. Getting to RLS implies the JWT was handled which ever type it is.

Note no one from Github is going to be able to check your project though only support can do that.

[false200]

Yeah this is a known pain point after rotating from legacy HS256 to ECC (ES256). auth.getUser() passing while .from().insert() hits RLS usually means the token is fine for Auth but PostgREST isn't actually running your request as authenticated.

Your SQL editor test with set local role authenticated only proves the policies work in Postgres. It doesn't prove the live REST request is getting the same JWT context. Different code path entirely.

What's probably going on

After rotation Auth starts signing access tokens with ES256. PostgREST picks up the role for RLS from Authorization: Bearer <access_token> (see https://supabase.com/docs/guides/auth/jwts).

If PostgREST can't verify that ES256 token against the current JWKS (sync lag after rotation is the usual suspect), it often won't even give you a 401. It just treats you as anon. Then auth.uid() is null, current_user is anon, and even a wide open insert to authenticated with check (true) still throws 42501.

That fits what you're seeing. GaryAustin1's point about reaching RLS is fair, but the JWT might still be getting handled as anon rather than authenticated.

getUser() working doesn't contradict this. GoTrue verifies its own tokens fine. That doesn't mean your failing insert request actually sent the bearer token.

First thing I'd do

Drop in a debug RPC and call it from the same deployed client that's failing, not the dashboard.

create or replace function public.debug_request_jwt()
returns jsonb
language sql
stable
security invoker
as $$
  select jsonb_build_object(
    'current_user', current_user,
    'role_claim', current_setting('request.jwt.claim.role', true),
    'sub_claim', current_setting('request.jwt.claim.sub', true),
    'auth_uid', auth.uid(),
    'auth_role', auth.role()
  );
$$;

grant execute on function public.debug_request_jwt() to anon, authenticated;

const { data: session } = await supabase.auth.getSession()
console.log('access_token alg:', JSON.parse(atob(session.session.access_token.split('.')[0])).alg)

const { data, error } = await supabase.rpc('debug_request_jwt')
console.log({ data, error })

const { error: insertError } = await supabase.from('your_table').insert({ /* your row */ })
console.log({ insertError })

If you get back current_user = authenticated and the right auth_uid, the JWT is reaching PostgREST and you're probably looking at table/column/policy shape on the insert itself.

If you get anon with null claims, the live request isn't authenticated. Check headers, client setup, or a platform JWKS sync bug.

If the RPC looks good but insert still fails, open Network tab and compare the two requests. Insert might be missing Authorization.

Check the actual failing request

In DevTools on the 42501 insert you want both headers present

Authorization: Bearer eyJ...
apikey: eyJ...

The bearer one must be session.access_token (ES256 after rotation). The apikey is your anon/publishable key, different thing.

Stuff I've seen after rotation

Client still holding an old HS256 token in localStorage
Server route or custom fetch sending apikey only
SSR supabase client with no session cookies so everything goes out as anon

Worth forcing a clean session before retesting

await supabase.auth.signOut()
await supabase.auth.signInWithPassword({ email, password })

or refreshSession(). Rotation docs are here https://supabase.com/docs/guides/auth/signing-keys

Gateway logs

Dashboard → Logs → API. Find the failed insert and check what role got decoded from the JWT in the log detail. If it says anon, you're not authenticated on that request even if Auth itself is happy.

Token sanity check

Decode your access token locally (don't post the full thing here). Header should show ES256, payload should have "role": "authenticated" and a valid sub. Also peek at

GET https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json

and make sure the token kid matches something in there.

If RPC returns anon but Authorization clearly has a valid ES256 token

That's when I'd stop debugging in SQL and open a support ticket. Nobody on GitHub can poke your project infra. Send them project ref, roughly when you rotated, request id from logs, the RPC output, and the token alg/kid (not the full jwt). Mention that permissive insert to authenticated still 42501 over REST.

Similar reports
#43066
#46303

Probably not the problem

Your RLS SQL (you already proved that in the editor)
Restart alone fixing a stale JWKS cache on their side
Auth being "broken" in general

Short version

getUser() ok does not mean PostgREST sees you as authenticated. Run the debug RPC from the failing app. 42501 on check true almost always means anon. Sign out/in or refresh after rotation. Verify Authorization on the insert in network tab. If all that looks correct, support ticket.

Happy to look at your RPC output if you paste it (redact uuids).

[harrysun2006]

Your instinct about the JWT signing key rotation is very likely right, and the "works in the SQL editor with claims set manually, fails from the live app" split is the tell.

Here's the mechanism: auth.getUser() succeeding only proves the Auth service can validate the token — Auth uses its own verification path. PostgREST verifies the JWT independently, and when it can't verify a token's signature it doesn't error loudly — it silently falls back to the anon role with no claims. So auth.uid() is NULL, request.jwt.claims is empty, and even a with check (true) policy for authenticated rejects the request, because the request isn't running as authenticated at all. That matches everything you're seeing.

After a rotation from HS256 → ECC (P-256), the usual causes are:

1. Stale tokens. Any session minted before the rotation was signed by the old key. If the old key was moved out of the verification set (or the client is still replaying an old access token), PostgREST can't verify it. Force a fresh token: sign the user out/in, or trigger a refresh, so the access token is signed by the now-active key.
2. kid not in the JWKS. Decode the failing access token (jwt.io) and check its header kid against https://<ref>.supabase.co/auth/v1/.well-known/jwks.json. If the token's kid isn't in that set, that's your smoking gun — PostgREST won't trust it.
3. Verification key set during migration. In Settings → JWT Keys, the newly rotated key should be the current signing key, and the previous key should remain in the standby/verification set until all old sessions expire. If the legacy key was fully removed too soon, in-flight sessions break.

Start with #2 — the kid-vs-JWKS check tells you immediately whether it's a stale token (re-login fixes it) or the project's key set is genuinely inconsistent. If freshly-minted tokens still have a kid that isn't in the published JWKS, that's a platform-side rotation problem and worth a support ticket with the project ref and a sample (redacted) token header.