auth.uid() returns NULL in RLS for live PostgREST requests despite a valid JWT (new JWT Signing Keys) — error 42501, reproduces on a fresh project

[xAsah]

Project ref: pywexoexxcxrrrxfvqgf (also reproduced identically on jdpoayuhktbbljdkxwqv)

Summary: Authenticated REST requests fail RLS because auth.uid() returns NULL at runtime, even though the request carries a valid Authorization: Bearer access token with the correct sub. This happens on a brand-new project with a fresh schema and reproduces on a second project.

Symptom: POST /rest/v1/grupy → 403, Proxy-Status: PostgREST; error=42501, body {"code":"42501","message":"new row violates row-level security policy for table "grupy""}. Policy: with check (wlasciciel_id = auth.uid()). The wlasciciel_id sent equals the user's auth UID exactly (34f4d443-1fc5-4745-877d-8b89461ad33e), confirmed in Authentication → Users. The Authorization header contains the user's session token (distinct from the apikey) with the correct sub.

Proof it is NOT the schema/app — running in the SQL editor with claims set manually works:

begin;
select set_config('request.jwt.claims','{"sub":"34f4d443-1fc5-4745-877d-8b89461ad33e","role":"authenticated"}', true);
set local role authenticated;
select auth.uid(); -- returns 34f4d443-... correctly
insert into public.grupy (nazwa, wlasciciel_id)
values ('Test','34f4d443-1fc5-4745-877d-8b89461ad33e'); -- succeeds, passes RLS
rollback;

So auth.uid() and the policies are correct. The failure is purely that live PostgREST requests do not propagate JWT claims into the DB session (request.jwt.claims is empty at runtime → auth.uid() NULL).

JWT config / things already tried (no change):

• Project uses new JWT Signing Keys; access tokens carry a kid.
• Rotated the current signing key to Legacy HS256 (Shared Secret) and restarted the project — issue persisted.
• Switched the client key from the legacy anon JWT key to the publishable key (sb_publishable_...) — issue persisted.
• Tested in a clean browser with a fresh login, and on a brand-new project — identical 42501.

Request: Please investigate why JWT claims are not propagated to PostgreSQL for authenticated requests on this project despite valid tokens. This appears tied to the new JWT Signing Keys and reproduces on a fresh project.

[coderabbitai[bot]]

⚠️ Possible Duplicate Issue(s)

• JWT claims not being passed to PostgreSQL - auth.uid() and current_setting('request.jwt.claims') return NULL #43066

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Lakshya77089]

Hey — thanks for the detailed write-up. The manual SQL-editor repro is genuinely helpful, because it tells us exactly where the problem is not.

Since set_config('request.jwt.claims', …) + set local role authenticated makes both auth.uid() and the insert succeed, your schema, RLS policy, and auth.uid() are all correct. The only thing left is what you suspected: on the live request, PostgREST isn't seeing your user's claims, so it runs as anonymous, auth.uid() comes back NULL, and with check (wlasciciel_id = auth.uid()) fails with 42501.

request.jwt.claims ends up empty on a live request in only three ways:

1. The Authorization: Bearer header isn't carrying the user access token (very common: it's set to the anon/publishable key, which has no sub).
2. A token is sent but its signature/kid can't be verified (a key was revoked, or rotation left the client holding a token signed by a key the Data API no longer trusts) → falls back to anon.
3. The token is expired.

A 3-step check that pins it down — the key idea is to look at the exact token on the failing request, not the one you think you're sending:

Step 1 — Decode the on-the-wire token. DevTools → Network tab → click the failing POST /rest/v1/grupy → Request Headers → copy the Authorization value → decode at jwt.io. Confirm: role is authenticated (not anon), sub is your user UUID, exp is in the future, and it is not the same value as your apikey header. (New-keys gotcha: a sb_publishable_…/sb_secret_… key must go in the apikey header — it can't be used as a Bearer token.)

Step 2 — Confirm the platform accepts that exact token.

curl https://<project-ref>.supabase.co/auth/v1/user \
  -H "apikey: <your publishable or anon key>" \
  -H "Authorization: Bearer <the exact token from step 1>"

• 200 with your user → the token is valid and its signature is trusted. Continue to step 3.
• 401 → signing-key problem: the token's kid isn't trusted. Re-login to mint a fresh token signed by the current in-use key, make sure you didn't revoke a key whose tokens are still in flight, and if you revoked one too early move it back to standby so its tokens verify again. Then retry.

Step 3 — See exactly what Postgres receives (the decisive test).

create or replace function public.whoami()
returns jsonb language sql stable as $$
  select jsonb_build_object(
    'uid', auth.uid(),
    'role', auth.role(),
    'claims', current_setting('request.jwt.claims', true)
  );
$$;

curl -X POST https://<project-ref>.supabase.co/rest/v1/rpc/whoami \
  -H "apikey: <your publishable or anon key>" \
  -H "Authorization: Bearer <the exact token from step 1>" \
  -H "Content-Type: application/json" -d '{}'

• claims empty / role = anon → the user token isn't reaching the Data API (header not sent, overwritten by a proxy/SDK, set to the API key, or you're using a client instance without the session attached). Fix on the client side so the request goes out with the user access token in Authorization.
• claims populated with your sub and role = authenticated → auth.uid() works on live requests after all, and the original 42501 was transient (e.g. the session wasn't attached at the moment you tested). Re-run your insert; it should pass.

In ~95% of these reports the answer is step 1 or step 3: the Authorization header on the real request isn't the user's access token. Could you run the three steps and paste back: the decoded header from step 1 (you can redact the signature), the HTTP status from step 2, and the JSON from step 3? With those we'll know for certain whether this is client-side or a signing-key issue, and the exact fix.

One more thing that helps rule out a platform issue: which client are you using to send the request — supabase-js, a raw fetch/curl, or something else — and is the token set per-request or via a global header?

[Lakshya77089]

Hey — thanks for the detailed write-up. The manual SQL-editor repro is genuinely helpful, because it tells us exactly where the problem is not.

Since set_config('request.jwt.claims', …) + set local role authenticated makes both auth.uid() and the insert succeed, your schema, RLS policy, and auth.uid() are all correct. The only thing left is what you suspected: on the live request, PostgREST isn't seeing your user's claims, so it runs as anonymous, auth.uid() comes back NULL, and with check (wlasciciel_id = auth.uid()) fails with 42501.

request.jwt.claims ends up empty on a live request in only three ways:

1. The Authorization: Bearer header isn't carrying the user access token (very common: it's set to the anon/publishable key, which has no sub).
2. A token is sent but its signature/kid can't be verified (a key was revoked, or rotation left the client holding a token signed by a key the Data API no longer trusts) → falls back to anon.
3. The token is expired.

A 3-step check that pins it down — the key idea is to look at the exact token on the failing request, not the one you think you're sending:

Step 1 — Decode the on-the-wire token. DevTools → Network tab → click the failing POST /rest/v1/grupy → Request Headers → copy the Authorization value → decode at jwt.io. Confirm: role is authenticated (not anon), sub is your user UUID, exp is in the future, and it is not the same value as your apikey header. (New-keys gotcha: a sb_publishable_…/sb_secret_… key must go in the apikey header — it can't be used as a Bearer token.)

Step 2 — Confirm the platform accepts that exact token.

curl https://<project-ref>.supabase.co/auth/v1/user \
  -H "apikey: <your publishable or anon key>" \
  -H "Authorization: Bearer <the exact token from step 1>"

• 200 with your user → the token is valid and its signature is trusted. Continue to step 3.
• 401 → signing-key problem: the token's kid isn't trusted. Re-login to mint a fresh token signed by the current in-use key, make sure you didn't revoke a key whose tokens are still in flight, and if you revoked one too early move it back to standby so its tokens verify again. Then retry.

Step 3 — See exactly what Postgres receives (the decisive test).

create or replace function public.whoami()
returns jsonb language sql stable as $$
  select jsonb_build_object(
    'uid', auth.uid(),
    'role', auth.role(),
    'claims', current_setting('request.jwt.claims', true)
  );
$$;

curl -X POST https://<project-ref>.supabase.co/rest/v1/rpc/whoami \
  -H "apikey: <your publishable or anon key>" \
  -H "Authorization: Bearer <the exact token from step 1>" \
  -H "Content-Type: application/json" -d '{}'

• claims empty / role = anon → the user token isn't reaching the Data API (header not sent, overwritten by a proxy/SDK, set to the API key, or you're using a client instance without the session attached). Fix on the client side so the request goes out with the user access token in Authorization.
• claims populated with your sub and role = authenticated → auth.uid() works on live requests after all, and the original 42501 was transient (e.g. the session wasn't attached at the moment you tested). Re-run your insert; it should pass.

In ~95% of these reports the answer is step 1 or step 3: the Authorization header on the real request isn't the user's access token. Could you run the three steps and paste back: the decoded header from step 1 (you can redact the signature), the HTTP status from step 2, and the JSON from step 3? With those we'll know for certain whether this is client-side or a signing-key issue, and the exact fix.

One more thing that helps rule out a platform issue: which client are you using to send the request — supabase-js, a raw fetch/curl, or something else — and is the token set per-request or via a global header?

---

(For maintainers: opened #47161 adding a troubleshooting doc for this pattern.)

[harrysun2006]

This looks like the same root cause as the other post-JWT-signing-key reports: PostgREST can't verify the token's signature, so it silently downgrades the request to the anon role — and once you're anon, auth.uid() is NULL and your with check (wlasciciel_id = auth.uid()) policy fails with 42501. The reason it works in the SQL editor is that you're setting request.jwt.claims by hand there, so you're bypassing the verification step entirely and only testing the policy logic (which is correct).

The thing to check is whether the access token your app sends is actually verifiable by this project's current keys:

1. Decode the token (jwt.io) and compare its header kid against https://<ref>.supabase.co/auth/v1/.well-known/jwks.json. If the kid isn't in that JWKS, PostgREST won't trust it → anon → NULL auth.uid().
2. Confirm the token is a freshly minted one (sign out/in) so it's signed by the currently-active signing key, not a cached older token.
3. Confirm the request really carries Authorization: Bearer <user access_token> and that it's distinct from the apikey header (sounds like you've verified this).

What makes your report notable is that it reproduces on a brand-new project with fresh tokens. If a just-issued token's kid genuinely isn't present in the project's published JWKS, that's not something you can fix from the app side — it's a platform issue with the new asymmetric signing keys, and worth a support ticket referencing both project refs, with a redacted token header + the JWKS response so they can see the kid mismatch directly. If, on the other hand, the kid does match, then the next place to look is whether your client is attaching the token to the PostgREST call at all (a global supabase client created before the session is set can end up sending only the anon key).