Single-use refresh tokens + middleware refresh on every request = silent session loss

[joerizz23]

Bug Description

The recommended Supabase SSR middleware pattern calls supabase.auth.getUser() on every request to refresh the auth token. Since Supabase refresh tokens are single-use, this creates a race condition that silently kills user sessions.

The Problem

1. Browser has cookies with access token (expired or near-expiry) + refresh token
2. Middleware calls getUser() → Supabase server burns the old refresh token, issues new access + refresh tokens
3. Middleware sets new tokens in response cookies via setAll()
4. If the browser doesn't fully receive/process that response (interrupted navigation, rapid clicks, slow connection, tab backgrounded), the new cookies never land
5. Browser still has the old (now-invalidated) refresh token
6. Next request → middleware tries to refresh with the dead token → fails → user = null → user appears signed out

Reproduction

This happens in production with real users, not just edge cases:

• Double-clicking a nav link — two rapid requests both hit middleware, first one burns the refresh token, second one gets the invalidated token
• Slow connections — page navigates away before the response with new cookies arrives
• Backgrounded tabs — browser throttles the response
• Any JS-triggered navigation that interrupts a pending middleware response

Environment

• @supabase/ssr with Next.js 14 App Router
• Standard middleware pattern from Supabase docs (calling getUser() on every request)
• Production deployment on Vercel

Current Workaround

We had to implement a workaround:

1. Decode the JWT expiry in middleware before calling getUser() — only refresh when the token is within 2 minutes of expiry instead of on every request
2. Client-side recovery hook — if server-side session is lost, try getUser() client-side as a fallback before declaring the user signed out

// Middleware workaround: only refresh when actually needed
function needsRefresh(request: NextRequest): boolean {
  const tokenCookies = request.cookies.getAll()
    .filter(c => c.name.includes('-auth-token'))
    .sort((a, b) => a.name.localeCompare(b.name));

  if (tokenCookies.length === 0) return true;

  const raw = tokenCookies.map(c => c.value).join('');
  try {
    const parsed = JSON.parse(raw);
    const accessToken = parsed.access_token || parsed[0];
    // Decode JWT expiry without verification
    const payload = JSON.parse(Buffer.from(accessToken.split('.')[1], 'base64url').toString());
    const now = Math.floor(Date.now() / 1000);
    return payload.exp - now < 120; // only refresh within 2 min of expiry
  } catch {
    return true;
  }
}

Suggested Fix

The recommended middleware pattern should not call getUser() on every request. Either:

1. Check JWT expiry first — only call getUser() when the access token is actually near expiry (like our workaround above)
2. Make refresh tokens reusable within a short window (e.g., 30 seconds) — so if the same refresh token is presented twice, it returns the same new tokens instead of failing
3. Update the docs to warn about this race condition and recommend the expiry-check pattern

Option 2 would be the most robust fix since it eliminates the race condition at the source.

Impact

This causes silent session loss for users with no error message or explanation. They're just suddenly signed out and redirected to the login page. It's particularly bad on mobile (slower connections) and during active use (rapid navigation).

[ylemkimon]

Actually, they're allowed multiple uses in a specified time window by default. You can configure "Refresh token reuse interval" in https://supabase.com/dashboard/project/_/auth/sessions:

[mandarini]

Hi @joerizz23, thank you for opening this issue! I want to dig into this carefully because I think two of the load-bearing assumptions in your report are not quite what's actually happening, and I'd like to walk through what the SDK and the auth server are doing under the hood.

getUser() does not refresh the token on every call.

Tracing the path in auth-js: getUser() calls _useSession(), which calls __loadSession(). That function loads the session from storage and only triggers _callRefreshToken() if expires_at * 1000 - Date.now() < EXPIRY_MARGIN_MS, where EXPIRY_MARGIN_MS is 90 seconds. Otherwise it reuses the existing access token to call /user. So in practice, getUser() does the same thing your "suggested fix #1" proposes (only refresh near expiry), just with a 90s threshold instead of 120s. If your middleware is refreshing on every request, something else is invalidating the session early — it's not getUser() itself.

Refresh tokens are not strictly single-use.

As @ylemkimon kindly pointed out, the auth server has a configurable Refresh Token Reuse Interval (Authentication → Sessions in the dashboard, default 10 seconds) where a revoked refresh token can be presented again and returns the same new pair. This is essentially your "suggested fix #2" and it already exists.

There's also a second safeguard on top of that: if the presented refresh token is the parent of the currently active one (meaning the client got a new pair but failed to store it), the server returns the currently active token instead of erroring. That covers the "browser didn't receive the response cookies" case directly.

What I'd actually recommend.

For middleware that just needs to gate access, use getClaims() instead of getUser(). With asymmetric JWT signing keys (the default for new projects), it verifies the JWT locally against a cached JWKS, with no auth-server call and no refresh churn at all. getUser() is the right tool when you specifically need a fresh user record from the database (current roles, email confirmation status, etc), but most middleware authorization checks don't need that.

If you do stick with getUser() and you're still seeing trouble from interrupted responses, bumping the Refresh Token Reuse Interval (say 10s to 30s) covers most of the "browser didn't fully process the new cookies" cases.

There's a genuine narrow race for parallel requests that arrive with an already-expired access token outside the reuse window, and we do call that out in the README under "Concurrent requests with the same expired session." But the getUser()-on-every-request framing isn't the mechanism causing it.

That said, the docs lean on getUser() heavily and could do a better job pointing people at getClaims() for the middleware-authorization use case. I'll take that part as actionable feedback.

Let me know if you give getClaims() a try in your middleware and whether it changes what you're seeing in production. Happy to keep looking if there's something specific to your setup that doesn't fit the picture above.

I am going to close this issue since this is not a bug with @supabase/ssr, but feel free to ask me anything else if you are still having trouble.