Skip to content

Supabase Auth errorSupabase users logged out with “Invalid Refresh Token”

Users are signed out at random, and the logs or console show Invalid Refresh Token: Refresh Token Not Found, or Already Used. Supabase refresh tokens work once, and a token used twice can end the whole session. Here’s how that works in Supabase’s words, and what to check, or hand it over at a fixed price.

Short answer

Each Supabase refresh token can be exchanged only once, for a new access and refresh token pair. Reuse is allowed within a 10-second interval by default, or when the parent of the active token is used; otherwise Supabase treats the whole session as terminated and revokes all its refresh tokens. Look for two places refreshing with the same token, such as the server and the browser, or an app restoring an older saved session.

Why the session ends, and the fix

  1. 01

    A refresh token used twice ended the session

    “the whole session is regarded as terminated and all refresh tokens belonging to it are marked as revoked.” Supabase, User sessions

    Supabase allows reuse within a short interval, 10 seconds by default, and returns the active token if the parent of the current one is used. Any other reuse ends that user’s session. We look for two parts of the app refreshing with the same token.

  2. 02

    The server and the browser both refresh

    “Using server-side rendering where the same refresh token needs to be reused on the server and soon after on the client” Supabase, User sessions

    Supabase built the reuse interval for this case. If the browser later refreshes with a token the server already exchanged, after the interval, the session ends. We check that whatever refreshes on the server writes the new tokens back to the cookie.

  3. 03

    The client retries with a token it already spent

    “and the response wasn't received and processed by the client, when the client comes back online, it will attempt to use the refresh token that was already used.” Supabase, User sessions

    Supabase describes a client that refreshed but never got the response, then comes back online and tries the old token again; outside the reuse interval that can end the session. We also check apps that store the session themselves, for example in a mobile app’s secure storage, so they always save the latest one.

Checked against the vendor’s docs on : Supabase docs: User sessions.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Supabase logs users out on page refresh · Supabase auth emails link to localhost · Supabase new row violates row-level security · Supabase public storage bucket

Questions

More on this error

Users drop when they reload the page. Is this the same?

Often not. A session lost on every reload is usually about where the session is stored and whether something refreshes it; see the session-lost-on-refresh fix linked below. This page is about refresh tokens being reused.

What about JWT expired errors?

Supabase access tokens are short-lived, usually between 5 minutes and 1 hour, and a refresh token is exchanged for a new pair. When requests fail with JWT expired, we first check whether the app refreshes the session at all, then look at reuse.

Should I turn off reuse detection?

Supabase says you can disable it in the Advanced Settings of the Auth settings page, though it is generally not recommended. It guards against refresh tokens stolen from leaking logs or vulnerable third-party servers.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.