TOKEN_REFRESHED loop on init with ECC P-256 signing key - SIGNED_OUT after 30 rapid refreshes

[AndyOgRD]

Describe the bug

On every page load, onAuthStateChange receives 30+ TOKEN_REFRESHED events in rapid succession (~100ms apart), followed by a SIGNED_OUT event that kills the session. This happens with zero Realtime channels active, with a clean localStorage, and regardless of supabase-js version (tested on 2.46.0 and 2.94.1).

Library affected

supabase-js

Reproduction

No response

Steps to reproduce

1.Have a Supabase project with ECC (P-256) as the active JWT signing key (migrated automatically by Supabase)
2.Create a React app with a standard AuthProvider using onAuthStateChange
3.Load the app with a valid session in localStorage
4.Observe console logs

1 INITIAL_SESSION event, then normal session behavior with TOKEN_REFRESHED firing at most once per hour.
Actual behavior
INITIAL_SESSION ← normal
TOKEN_REFRESHED ← fires BEFORE INITIAL_SESSION on some reloads
TOKEN_REFRESHED
SIGNED_OUT ← 5-6 seconds after INITIAL_SESSION
SIGNED_IN ← session re-established
TOKEN_REFRESHED ← rapid loop starts
TOKEN_REFRESHED ← ~100ms between each
TOKEN_REFRESHED ← 30+ times
...
SIGNED_OUT ← session killed by "refresh token already used"
Key observations

The loop starts before INITIAL_SESSION is processed — it originates inside the Supabase client initialization, not in application code
The loop occurs with zero Realtime channels active
The loop occurs with clean localStorage (all sb-* keys manually deleted)
A minimal test component with only 2 Realtime channels and no AuthProvider logic works perfectly — no TOKEN_REFRESHED loop
The project recently had its JWT signing key automatically migrated from Legacy HS256 to ECC (P-256) by Supabase
Supabase dashboard settings: Refresh token reuse interval: 30s, Detect and revoke compromised tokens: enabled
The SIGNED_OUT is caused by "refresh token already used" — multiple parallel refresh attempts consuming the same token within the reuse interval

System Info

@supabase/supabase-js: tested on 2.46.0 and 2.94.1 — same behavior on both
@supabase/auth-js: 2.94.1
@supabase/realtime-js: 2.94.1
Browser: Chrome (Windows)
JWT Signing Key: ECC (P-256) (migrated automatically, Legacy HS256 still present as "Previously used key")
React 18, Vite

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Supabase JS Library issue and not an issue with the Supabase platform. If it's a Supabase platform related bug, it should likely be reported to supabase/supabase instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[mandarini]

Thanks for the detailed report!! After lots of digging in the auth server code and auth-js here's what I found:

• Inside GoTrueClient, a shared navigator lock serializes all auth operations. When an operation holds the lock, any other auth call that arrives queues up in an internal pendingInLock array and runs sequentially once the primary operation releases (see _acquireLock in GoTrueClient.ts).

• The relevant part of _callRefreshToken (the function that actually hits /token?grant_type=refresh_token):

// GoTrueClient.ts ~line 2707
this.refreshingDeferred = new Deferred<CallRefreshTokenResult>()
// ... calls _refreshAccessToken, saves session, then:
await this._notifyAllSubscribers('TOKEN_REFRESHED', data.session)
// ... finally:
this.refreshingDeferred = null

• _notifyAllSubscribers awaits every subscriber callback (await Promise.all(promises)). This means subscriber code runs while the lock is still held and refreshingDeferred has already been set to null (in the finally block).

• Meanwhile, __loadSession() — called by getSession(), getUser(), and several other methods — independently checks token expiry and calls _callRefreshToken() if the token is within the 90-second margin:

// GoTrueClient.ts ~line 1664
const hasExpired = currentSession.expires_at
  ? currentSession.expires_at * 1000 - Date.now() < EXPIRY_MARGIN_MS  // EXPIRY_MARGIN_MS = 90,000ms
  : false

// line 1708 — if hasExpired:
const { data: session, error } = await this._callRefreshToken(currentSession.refresh_token)

This creates a feedback loop when certain conditions are met:

1. _callRefreshToken() runs inside the lock → saves new session → emits TOKEN_REFRESHED
2. Subscriber callback fires (still inside the lock) → calls getSession() or getUser()
3. That call goes into pendingInLock because lockAcquired = true
4. _callRefreshToken() finishes → refreshingDeferred = null
5. Lock drains the queue → getSession() runs → __loadSession() checks expiry again → finds token still within the 90s margin → calls _callRefreshToken() fresh (no deduplication because refreshingDeferred is null)
6. TOKEN_REFRESHED emitted again → go to step 2

So, why it ends in SIGNED_OUT: the auth server correctly handles concurrent/rapid refresh requests — within the refresh token reuse interval (your project has 30s), it recognises the concurrent pattern and returns the same token without error. Each successful response causes the client to emit TOKEN_REFRESHED.

Once the 30s reuse window expires, a refresh request arrives with a token that is now genuinely "already used" and outside the grace period. Since you have "Detect and revoke compromised tokens" enabled, the server treats this as a potential token theft and revokes the entire token family → SIGNED_OUT.

The server is behaving correctly by design. The problem is the client generating far more refresh requests than should ever happen.

The two most likely root causes are these

1. Calling getSession() or getUser() inside onAuthStateChange

This is the most common. If your onAuthStateChange callback calls any auth method that internally goes through __loadSession(), you can create the loop described above.

Problematic pattern:

supabase.auth.onAuthStateChange(async (event, session) => {
  // This queues inside the lock and can re-trigger _callRefreshToken
  const { data: { user } } = await supabase.auth.getUser()
  // or
  const { data: { session: freshSession } } = await supabase.auth.getSession()
  setUser(user)
})

Correct pattern — use the session parameter directly:

supabase.auth.onAuthStateChange((event, session) => {
  // session is already the current, fresh session — no need to re-fetch
  setSession(session)
  setUser(session?.user ?? null)
})

The session argument passed to onAuthStateChange is always the up-to-date session at the time of the event. You never need to call getSession() inside the callback.

If you genuinely need server-validated user data (i.e., you want getUser() for security-sensitive checks), do it outside the callback, triggered by state changes, not inside it.

2. JWT expiry set below the 90-second auto-refresh margin

auth-js starts trying to refresh a token when it is within 90 seconds of expiry (EXPIRY_MARGIN_MS = 90_000). The auto-refresh ticker also fires when expiresInTicks <= 3 (3 × 30s ticks = 90s).

If your project's JWT expiry is configured to ≤ 90 seconds, then every single session will look expired the moment it's retrieved, causing an immediate and infinite refresh loop:

• Token returned with expires_at = now + 60s
• __loadSession() checks: 60,000ms < 90,000ms → hasExpired = true
• Refreshes → gets new token with same short expiry → hasExpired = true immediately → repeat

Check your JWT expiry in the Supabase dashboard:
Go to Authentication → Settings → JWT expiry limit. It must be greater than 90 seconds. The default is 3600 seconds (1 hour) and we strongly recommend keeping it at 3600s or higher.

3. Multiple GoTrueClient instances (secondary cause)

If createClient() is called more than once in your app — for example inside a React component that re-renders, or without a module-level singleton — multiple clients independently run their own auto-refresh tickers and onAuthStateChange listeners, all racing on the same refresh token. Each instance has its own refreshingDeferred so the deduplication doesn't work across instances.

// Wrong — creates a new client on every render
function MyComponent() {
  const supabase = createClient(URL, ANON_KEY)
  // ...
}

// Correct — singleton at module level
// lib/supabase.ts
export const supabase = createClient(URL, ANON_KEY)

On the ECC P-256 correlation

I looked into the auth server token refresh path in detail. The JSON response from /token?grant_type=refresh_token includes both expires_in and expires_at as mandatory fields. Neither is conditional on the signing algorithm, and their values are derived purely from your project's JWT_EXP configuration which does not change when the signing key is rotated. The key rotation is a pure cryptographic change (what algorithm signs the JWT), with no effect on session lifetime, token response format, or any other auth configuration.

My best hypothesis is that the key migration happened around the same time as whatever code change introduced one of the patterns above, creating a false correlation. The 30+ refresh loop is reproducible on HS256 projects too if the same conditions are met.

That said, if you can confirm your JWT expiry is set correctly (> 90s) and you're not calling auth methods inside onAuthStateChange, please share a minimal reproducible example. That would help us determine if there's a genuine library bug hiding behind the common footguns.

Can you please check each of the following:

• JWT expiry (Dashboard → Auth → Settings → JWT expiry limit): is it greater than 90 seconds?
• onAuthStateChange callback: does it call supabase.auth.getSession(), supabase.auth.getUser(), or any other Supabase auth method?
• Single client instance: is createClient() called once at the module level (not inside a component, context provider render function, or hook without useMemo)?
• React Strict Mode: are you seeing this in development only? React Strict Mode double-invokes effects, which can expose race conditions in client initialization.
• BroadcastChannel / multiple tabs: are there multiple tabs of your app open when this occurs?

If you need immediate relief while diagnosing, as a temporary workaround, you can prevent the loop by ensuring your onAuthStateChange callback is side-effect-free with respect to auth:

const { data: { subscription } } = supabase.auth.onAuthStateChange((event, session) => {
  // Only use the provided session/event — never call auth methods here
  if (event === 'SIGNED_IN' || event === 'TOKEN_REFRESHED') {
    setSession(session)
  } else if (event === 'SIGNED_OUT') {
    setSession(null)
  }
})

And initialize your session state separately, once, before setting up the listener:

// Get initial session without going through onAuthStateChange
const { data: { session } } = await supabase.auth.getSession()
setSession(session)

// Then listen for changes
supabase.auth.onAuthStateChange((event, session) => {
  setSession(session)
})

Let me know if this helps, and can you please report back with what you found?

[AndyOgRD]

thanks a lot, i will use it and i would talk you if something more happen.... i really aprecciate El vie, 20 feb 2026 a las 6:31, Katerina Skroumpelou (< ***@***.***>) escribió:

…

*mandarini* left a comment (supabase/supabase-js#2126) <#2126 (comment)> Thanks for the detailed report!! After lots of digging in the auth server code <https://github.com/supabase/auth> and auth-js here's what I found: - Inside GoTrueClient, a shared *navigator lock* serializes all auth operations. When an operation holds the lock, any other auth call that arrives queues up in an internal pendingInLock array and runs sequentially once the primary operation releases (see _acquireLock in GoTrueClient.ts <https://github.com/supabase/supabase-js/blob/master/packages/core/auth-js/src/GoTrueClient.ts> ). - The relevant part of _callRefreshToken (the function that actually hits /token?grant_type=refresh_token): // GoTrueClient.ts ~line 2707this.refreshingDeferred = new Deferred<CallRefreshTokenResult>()// ... calls _refreshAccessToken, saves session, then:await this._notifyAllSubscribers('TOKEN_REFRESHED', data.session)// ... finally:this.refreshingDeferred = null - _notifyAllSubscribers *awaits* every subscriber callback (await Promise.all(promises)). This means subscriber code runs *while the lock is still held* and refreshingDeferred has already been set to null (in the finally block). - Meanwhile, __loadSession() — called by getSession(), getUser(), and several other methods — independently checks token expiry and calls _callRefreshToken() if the token is within the 90-second margin: // GoTrueClient.ts ~line 1664const hasExpired = currentSession.expires_at ? currentSession.expires_at * 1000 - Date.now() < EXPIRY_MARGIN_MS // EXPIRY_MARGIN_MS = 90,000ms : false // line 1708 — if hasExpired:const { data: session, error } = await this._callRefreshToken(currentSession.refresh_token) *This creates a feedback loop when certain conditions are met:* 1. _callRefreshToken() runs inside the lock → saves new session → emits TOKEN_REFRESHED 2. Subscriber callback fires (still inside the lock) → calls getSession() or getUser() 3. That call goes into pendingInLock because lockAcquired = true 4. _callRefreshToken() finishes → refreshingDeferred = null 5. Lock drains the queue → getSession() runs → __loadSession() checks expiry again → finds token still within the 90s margin → calls _callRefreshToken() fresh (no deduplication because refreshingDeferred is null) 6. TOKEN_REFRESHED emitted again → go to step 2 So, why it ends in SIGNED_OUT: the auth server correctly handles concurrent/rapid refresh requests — within the *refresh token reuse interval* (your project has 30s), it recognises the concurrent pattern and returns the same token without error. Each successful response causes the client to emit TOKEN_REFRESHED. Once the 30s reuse window expires, a refresh request arrives with a token that is now genuinely "already used" and outside the grace period. Since you have *"Detect and revoke compromised tokens"* enabled, the server treats this as a potential token theft and *revokes the entire token family* → SIGNED_OUT. The server is behaving correctly by design. The problem is the client generating far more refresh requests than should ever happen. The two most likely root causes are these 1. Calling getSession() or getUser() inside onAuthStateChange This is the most common. If your onAuthStateChange callback calls any auth method that internally goes through __loadSession(), you can create the loop described above. *Problematic pattern:* supabase.auth.onAuthStateChange(async (event, session) => { // This queues inside the lock and can re-trigger _callRefreshToken const { data: { user } } = await supabase.auth.getUser() // or const { data: { session: freshSession } } = await supabase.auth.getSession() setUser(user)}) *Correct pattern — use the session parameter directly:* supabase.auth.onAuthStateChange((event, session) => { // session is already the current, fresh session — no need to re-fetch setSession(session) setUser(session?.user ?? null)}) The session argument passed to onAuthStateChange is always the up-to-date session at the time of the event. You never need to call getSession() inside the callback. If you genuinely need server-validated user data (i.e., you want getUser() for security-sensitive checks), do it outside the callback, triggered by state changes, not inside it. 2. JWT expiry set below the 90-second auto-refresh margin auth-js starts trying to refresh a token when it is within *90 seconds of expiry* (EXPIRY_MARGIN_MS = 90_000). The auto-refresh ticker also fires when expiresInTicks <= 3 (3 × 30s ticks = 90s). If your project's JWT expiry is configured to *≤ 90 seconds*, then *every single session will look expired the moment it's retrieved*, causing an immediate and infinite refresh loop: - Token returned with expires_at = now + 60s - __loadSession() checks: 60,000ms < 90,000ms → hasExpired = true - Refreshes → gets new token with same short expiry → hasExpired = true immediately → repeat *Check your JWT expiry in the Supabase dashboard:* Go to *Authentication → Settings → JWT expiry limit*. It must be greater than 90 seconds. The default is *3600 seconds (1 hour)* and we strongly recommend keeping it at 3600s or higher. 3. Multiple GoTrueClient instances (secondary cause) If createClient() is called more than once in your app — for example inside a React component that re-renders, or without a module-level singleton — multiple clients independently run their own auto-refresh tickers and onAuthStateChange listeners, all racing on the same refresh token. Each instance has its own refreshingDeferred so the deduplication doesn't work across instances. // Wrong — creates a new client on every renderfunction MyComponent() { const supabase = createClient(URL, ANON_KEY) // ...} // Correct — singleton at module level// lib/supabase.tsexport const supabase = createClient(URL, ANON_KEY) On the ECC P-256 correlation I looked into the auth server token refresh path in detail. The JSON response from /token?grant_type=refresh_token includes both expires_in and expires_at as mandatory fields. Neither is conditional on the signing algorithm, and their values are derived purely from your project's JWT_EXP configuration which does *not* change when the signing key is rotated. The key rotation is a pure cryptographic change (what algorithm signs the JWT), with no effect on session lifetime, token response format, or any other auth configuration. My best hypothesis is that the key migration happened *around the same time* as whatever code change introduced one of the patterns above, creating a false correlation. The 30+ refresh loop is reproducible on HS256 projects too if the same conditions are met. That said, if you can confirm your JWT expiry is set correctly (> 90s) and you're not calling auth methods inside onAuthStateChange, please share a *minimal reproducible example*. That would help us determine if there's a genuine library bug hiding behind the common footguns. Can you please check each of the following: - *JWT expiry* (Dashboard → Auth → Settings → JWT expiry limit): is it greater than 90 seconds? - *onAuthStateChange callback*: does it call supabase.auth.getSession(), supabase.auth.getUser(), or any other Supabase auth method? - *Single client instance*: is createClient() called once at the module level (not inside a component, context provider render function, or hook without useMemo)? - *React Strict Mode*: are you seeing this in development only? React Strict Mode double-invokes effects, which can expose race conditions in client initialization. - *BroadcastChannel / multiple tabs*: are there multiple tabs of your app open when this occurs? If you need immediate relief while diagnosing, as a *temporary workaround*, you can prevent the loop by ensuring your onAuthStateChange callback is side-effect-free with respect to auth: const { data: { subscription } } = supabase.auth.onAuthStateChange((event, session) => { // Only use the provided session/event — never call auth methods here if (event === 'SIGNED_IN' || event === 'TOKEN_REFRESHED') { setSession(session) } else if (event === 'SIGNED_OUT') { setSession(null) }}) And initialize your session state separately, once, before setting up the listener: // Get initial session without going through onAuthStateChangeconst { data: { session } } = await supabase.auth.getSession()setSession(session) // Then listen for changessupabase.auth.onAuthStateChange((event, session) => { setSession(session)}) Let me know if this helps, and can you please report back with what you found? — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5JZO52OOMAVHHC2BKXBZ7D4M3O7JAVCNFSM6AAAAACVWUCVC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZSHE2TANRXGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[xXMrNidaXx]

Analysis: Race Condition in Concurrent Refresh

This looks like a classic race condition between multiple token refresh attempts. Here's what's happening:

Root Cause

1. Supabase Client Initialization starts a background token refresh check
2. AuthProvider/onAuthStateChange triggers INITIAL_SESSION handling, which may also start refresh
3. Multiple parallel refreshAccessToken() calls use the same refresh token
4. First refresh succeeds → new refresh token issued, old one invalidated
5. Second refresh attempts → "refresh token already used" → SIGNED_OUT

With "Detect and revoke compromised tokens" enabled, the server sees rapid reuse of the same token and flags it as a potential replay attack.

Why ECC Matters

The migration to ECC P-256 likely changed token validation timing. ECC signature verification is faster than HS256, which could expose previously hidden race conditions if:

• Token validation now completes faster, allowing more concurrent refreshes before the first one locks
• The migration triggered client-side logic that re-validates/refreshes the existing session

Immediate Workaround

Disable concurrent refresh in your client config:

const supabase = createClient(url, key, {
  auth: {
    autoRefreshToken: false, // Disable auto-refresh
    persistSession: true,
  },
});

// Manual refresh with mutex
let refreshing = false;
async function safeRefresh() {
  if (refreshing) return;
  refreshing = true;
  try {
    await supabase.auth.refreshSession();
  } finally {
    refreshing = false;
  }
}

// Call safeRefresh in your auth state handler

Longer-Term Fix

The SDK should implement a refresh mutex internally:

// In auth-js GoTrueClient
private refreshPromise: Promise<void> | null = null;

async _refreshAccessToken() {
  if (this.refreshPromise) return this.refreshPromise;
  
  this.refreshPromise = this._doRefresh().finally(() => {
    this.refreshPromise = null;
  });
  
  return this.refreshPromise;
}

This ensures only one refresh runs at a time, and other callers await the same promise.

To Confirm

Can you log the timestamps on TOKEN_REFRESHED events? If they're all within the same ~30s window (your reuse interval), it confirms multiple callers hitting the same token before the first refresh completes.

---

RevolutionAI - debugging auth edge cases