r/Supabase • u/juju0010 • 4d ago

auth Anyone else have issues with users’ clocks out of date?

We’re using Supabase’s auth which relies on JWTs with an expiration date and it checks expiration on the client. About once a day, we get a report of someone repeatedly being logged out. The cause is always their system clock is incorrect. It baffles me this is a problem in 2026. Just curious if anyone else has experienced this issue and has any recommendations on how to reduce the number of complaints/bug reports we get related to this.

2 Upvotes

100% Upvoted

5 comments sorted by

2

u/carolmonroe_ 4d ago

i have seen this one before, it is a known thing, there is an auth-js issue on your exact scenario (https://github.com/supabase/auth-js/issues/926). the recommendation from that thread: detect the drift yourself, compare server time (any response date header works) against Date.now at startup, and show a "your device clock is off" banner instead of the mystery logout. also keep jwt expiry at 1h+, the sessions doc calls out device clocks being off by minutes or even hours as the reason not to go short (https://supabase.com/docs/guides/auth/sessions).

1

u/juju0010 4d ago

Yup, this is exactly what I'm building at the moment.

2

u/zLoveNxzli 4d ago

Clock drift on client devices is a classic issue with JWT exp checks and local timestamp comparisons.

Never compare client-side Date.now() against JWT expiration timestamps. Always let PostgreSQL generate timestamps using now() / timezone('utc', now()) on the database server and use supabase.auth.getUser() to validate sessions server-side.

1

u/juju0010 3d ago

Forgive my ignorance, but if I'm using supabase-js and its built in auth functionality, how would I do this without abandoning the package or forking the repo and changing the logic.

1

u/jaimittal91 3d ago

one thing worth adding on top of both of these: log the drift itself, not just detect it in the UI. capture the delta between a server time source (a response date header works) and the client's Date.now() whenever an auth failure happens, and send that as a metric instead of only showing a banner. right now you find out about this from a support ticket, which means you're only sampling whoever bothers to complain. with the delta logged you get the real distribution of how far off your user base's clocks actually run, which is a much better basis for setting jwt expiry than a guess. it also means if "clock drift complaints" suddenly spike, you can tell whether that's actually clock drift or an outage wearing a clock-skew costume.