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.