Fresh Supabase Auth JWT rejected by PostgREST: PGRST303 “JWT issued at future”

[ezhuvam]

Project region: Singapore / ap-southeast-1
Supabase support ticket: SU-427553

A fresh Supabase Auth session succeeds:

GET /auth/v1/user → HTTP 200

But an immediate request to the same project’s Data API fails:

GET /rest/v1/clients → HTTP 401

Response:

{
"code": "PGRST303",
"details": null,
"hint": null,
"message": "JWT issued at future"
}

Reproduced using:

• A completely fresh Incognito session
• A newly signed-in user
• Automatically synchronized Windows date/time
• @supabase/supabase-js managed session

We do not mint, modify, decode, or manually attach custom JWTs.
The frontend does not weaken JWT validation.
The Auth endpoint accepts the session, while PostgREST rejects the same fresh JWT.

Could this indicate project-specific clock skew or signing/auth synchronization between Auth and PostgREST?

[k1ng-arthur]

File a support ticket, there was another issue on reddit i responded to and suggested restarting https://www.reddit.com/r/Supabase/comments/1v11ze6/comment/oyuev3g/?context=1&screen_view_count=2 but it appears it was not persistent

[initial-d]

PGRST303: JWT issued at future is specifically about the token's iat claim being later than the clock used by PostgREST, after whatever clock-skew tolerance PostgREST allows.

Given your notes, I would check two things to separate a client-side problem from a project/service-side one:

1. Decode the fresh access token without verifying it and compare iat to real UTC time at the moment the Data API call fails.

In the browser console, after sign-in:

const { data } = await supabase.auth.getSession()
const token = data.session.access_token
const payload = JSON.parse(atob(token.split('.')[1].replace(/-/g, '+').replace(/_/g, '/')))
console.log({
  iat: payload.iat,
  iatUtc: new Date(payload.iat * 1000).toISOString(),
  nowUtc: new Date().toISOString(),
  skewSeconds: payload.iat - Math.floor(Date.now() / 1000),
})

If skewSeconds is positive by more than a few seconds, the token really is minted in the future relative to the client machine. If the client clock is correct and this still happens, that points away from your app code.

2. Retry the same Data API call after 30-90 seconds with the same session.

If it starts working after waiting, that strongly supports a small clock skew between Auth token issuance and the PostgREST validator. If it never works, then it may be a different JWT validation/config issue even though the error wording is about iat.

Since you are not minting custom JWTs and /auth/v1/user accepts the same session, I would not work around this in the frontend by delaying every request unless you only need a temporary mitigation. The durable fix should be on the project/service side: Auth and PostgREST need clocks/configuration that agree.

For the support ticket, I would include:

• project ref and region
• one failing request timestamp in UTC
• decoded iat, exp, iss, aud, and role claims, but not the full token
• whether the same token succeeds after a 30-90s delay
• confirmation that Windows time sync is enabled and no custom JWT is used

That gives Supabase enough evidence to check for clock skew or service synchronization on the project without needing your raw token.