Supabase Auth accepts user JWT (200), but PostgREST rejects the same JWT with PGRST303

[kyxrap]

Hello,

I'm experiencing an issue that completely prevents users from accessing my application.

Using the exact same user access token and publishable API key, direct requests produce different results:

GET /auth/v1/user → HTTP 200, authenticated user returned.

GET /rest/v1/profiles?select=role&id=eq. → HTTP 401, PGRST303: JWT issued at future.

These tests were performed directly, independently of the application's frontend authentication and role-loading logic.

Additional findings:

The PostgreSQL database is accessible through the Supabase dashboard.

The local machine and database clocks are consistent.

The legacy service_role JWT successfully accesses the database RPC.

An sb_secret_ API key previously received the same PGRST303 error.

The organization is below its Free Plan usage limits.

The issue persists in a private browsing session.

Project reference: vjddbwdfapneeddqhpho

Latest reproduction: October 17, 2026, approximately 20:22 UTC.

Could someone from the Supabase team investigate why PostgREST rejects a JWT that Supabase Auth accepts, specifically reporting that it was issued in the future?

Is there a known issue involving JWT timestamp validation or clock synchronization between Auth and the Data API?

The issue is currently blocking access to my application.

Thank you.

[somuai]

Root Cause Analysis & Resolution: PostgREST PGRST303 Clock Skew

The symptom where Supabase Auth (/auth/v1/user) accepts a newly minted JWT with HTTP 200 while PostgREST (/rest/v1/*) rejects the exact same token with HTTP 401 / PGRST303: JWT issued at future is caused by a clock skew exceeding 30 seconds between the GoTrue (Auth) service and the PostgREST container.

Here is the exact architectural and code-level breakdown of why this happens, why your legacy keys still function, and how to resolve it immediately.

---

1. Code-Level Root Cause in PostgREST

In PostgREST's Haskell source code (src/library/PostgREST/Auth/Jwt.hs), claim validation enforces strict upper bounds on timestamps:

claim "iat" IatClaimNotNumber $ inTheFuture JWTIssuedAtFuture

where the future check is defined as:

inTheFuture = checkTime ((now + allowedSkewSeconds) <)
allowedSkewSeconds = 30 :: Int64

When a request arrives at /rest/v1, PostgREST compares the token's iat (Issued At) claim against its own container clock now plus a hardcoded 30-second allowance (allowedSkewSeconds = 30).

If iat > now + 30, PostgREST immediately aborts request execution and returns:

• HTTP Status: 401 Unauthorized
• Error Code: PGRST303
• Message: JWT issued at future

---

2. Why GoTrue Accepts the Token (HTTP 200) but PostgREST Rejects It

On hosted Supabase infrastructure, GoTrue (Auth), PostgREST (Data API), and PostgreSQL run as distinct containerized services:

1. GoTrue Service: When you sign in or refresh a session, GoTrue generates the token using its local host clock (iat = now_gotrue). When validating requests to /auth/v1/user, GoTrue verifies token signatures and expiration (exp), but does not apply PostgREST's rigid 30-second future iat threshold.
2. PostgREST Container: If the container hosting PostgREST experiences clock drift and falls behind true UTC by more than 30 seconds (e.g., 40-60 seconds behind UTC), then any newly minted token generated at true UTC will appear to PostgREST as having been "issued in the future".

---

3. Why Legacy service_role Works While Fresh User Tokens & sb_secret_ Fail

• Legacy service_role Key: The legacy service_role JWT was generated when your project was provisioned (days or weeks in the past). Its iat timestamp is in the distant past. As long as iat <= now, the condition is satisfied regardless of how far behind PostgREST's clock is drifting.
• Fresh User Tokens: Minted at runtime by GoTrue with iat reflecting the current second in true UTC. Because PostgREST's clock is lagging behind true UTC by >30 seconds, iat > PostgREST_now + 30s, tripping PGRST303.
• Fresh sb_secret_ Keys: Generated on-demand via the Supabase Dashboard / Control Plane at current UTC, similarly exceeding PostgREST's lagging clock boundary.

This pattern commonly surfaces on paused and resumed instances (such as Free Plan compute), where container hypervisor suspension can induce transient NTP synchronization drift before the container's time daemon reconciles with the host clock.

---

4. Resolution Steps

Step 1: Force PostgREST Service Clock Resynchronization

The fastest fix is to force the PostgREST container to restart and re-sync its system clock against the host hypervisor:

1. Open the Supabase Dashboard for project vjddbwdfapneeddqhpho.
2. Navigate to Project Settings -> Infrastructure.
3. Under Restart Services, click Restart Rest API (PostgREST).
   (Alternatively, under Project Settings -> General, perform a manual Pause followed by Resume).
4. Once PostgREST finishes initialization (~10-20 seconds), test your endpoint again:

   curl -i -H "apikey: <anon_key>" \
        -H "Authorization: Bearer <user_jwt>" \
        "https://vjddbwdfapneeddqhpho.supabase.co/rest/v1/profiles?select=role&id=eq.<user_id>"

Step 2: Verify PostgreSQL Database Clock Time

To verify that the underlying Postgres engine clock is aligned with UTC, run the following in the SQL Editor:

SELECT 
  NOW() AS transaction_time,
  clock_timestamp() AS wall_clock_time,
  NOW() AT TIME ZONE 'UTC' AS utc_now;

Compare utc_now against an external reference (such as time.is). If the database output matches true UTC, this confirms the issue was isolated to PostgREST container clock drift, which Step 1 will have resolved.

Step 3: Mitigation for Custom Token Issuers (If Applicable)

If your application generates custom JWTs outside GoTrue (e.g., from an external Node.js/Go auth backend), ensure the server running the token generator synchronizes with pool.ntp.org or chrony. You can also include a 30-to-60-second backdate buffer to protect against cross-server drift:

const iat = Math.floor(Date.now() / 1000) - 60; // 60s backdate buffer absorbs clock skew

[yos88da]

I can't find the cause in Supabase's docs, so here is a way to narrow it down rather than a fix.

1. Check how the keys are sent. Supabase's API keys page says publishable and secret keys are not JWTs: they go in the apikey header, not in the Authorization: Bearer header. The user's access token goes in Authorization. Make sure the publishable key is not also in that header: https://supabase.com/docs/guides/api/api-keys
2. Compare the clocks from outside. Send one request to /auth/v1/user and one to /rest/v1/... with curl -i, and look at the Date: header of each response. Then decode the middle part of the access token (the part between the two dots, base64) and read iat. If iat is ahead of the REST response's Date by more than a few seconds, that is concrete evidence for the ticket. (My suggestion, not from the docs.)
3. Sign out completely, sign in again, and call REST straight away. Fails every time = something systematic. Works after some seconds = timing.
4. Put the UTC times, both Date: values and the decoded iat into the support ticket. Leave out the project ref and tokens in public replies.

[solvionholdings]

The PostgREST docs explain the asymmetry. PostgREST validates the time-based claims exp, iat and nbf and allows 30 seconds of clock skew (https://docs.postgrest.org/en/stable/references/auth.html). "JWT issued at future" means the iat in your token is more than 30 s ahead of the clock on the host running PostgREST. Supabase Auth minted that iat from its own clock, so the two services disagree about the time.

That explains everything you saw:

• /auth/v1/user returns 200 because Auth checks the token against its own clock.
• The legacy service_role JWT works because its iat is years in the past, so skew can't push it into the future.
• Every freshly minted token fails (user sessions, and a fresh token behind your sb_secret_ request) because its iat is "now" by Auth's clock.

Your laptop's clock doesn't matter, because both the minting and the checking happen server-side.

To prove it in one request, decode the access token and compare iat with the Date header PostgREST sends back:

TOKEN=...   # user access token
curl -si "$SUPABASE_URL/rest/v1/profiles?select=id&limit=1" \
  -H "apikey: $PUBLISHABLE_KEY" -H "Authorization: Bearer $TOKEN" | grep -i '^date:'
# then: echo "$TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null   -> look at "iat"

If iat minus the Date header is more than about 30 s, you have server-side clock drift. You can't fix that in app code. Put the two timestamps, the sb-request-id response header and your project ref in the support ticket. The numbers show it's the platform, so the ticket can't be closed as a client bug. A project restart may move or restart the services and clear it in the meantime, but report it either way. Another user reported the same symptom on a different project the same day, so it may not be specific to yours.

Two things not to do while you wait:

• Don't switch the frontend to the secret or service_role key to get around the error. That bypasses RLS for every user.
• Don't try to fake iat on the client.

Also make sure the publishable or secret key goes in the apikey header only. It isn't a JWT, and only the user's access token belongs in Authorization: Bearer (https://supabase.com/docs/guides/api/api-keys).