The Problem Next.js 16 App Router + Django SimpleJWT: Users Randomly Logged Out Due to Parallel RSC Requests

[Avidan369]

Summary

Next.js 16 App Router + Django SimpleJWT: Users Randomly Logged Out Due to Parallel RSC Requests

Additional information

# Next.js 16 App Router + Django SimpleJWT: Users Randomly Logged Out Due to Parallel RSC Requests

## The Problem

Users get randomly logged out every ~9 minutes (the access token lifetime). The logout happens during normal navigation — no button clicks, just switching between pages.

**Django logs show the race condition clearly:**

11:24:42 → POST /api/login/refresh/auto/ → 200 ✅
11:24:42 → POST /api/login/refresh/auto/ → 401 ❌  ← same millisecond, logout

---

Architecture

• Frontend: Next.js 16.1.6 / React 19.2.4 / next-intl 4.7.0
• Backend: Django 6.0.2 / djangorestframework 3.16.1 / djangorestframework-simplejwt 5.5.1
• Deployment: VPS — Cloudflare → Nginx → Next.js (Node.js, npm run start) ↔ Django on localhost
• Auth flow: proxy.ts acts as auth middleware — reads httpOnly cookies, calls Django refresh endpoint when access token expires, sets new cookies

Django SimpleJWT config:

SIMPLE_JWT = {
"ACCESS_TOKEN_LIFETIME": timedelta(minutes=13),
"REFRESH_TOKEN_LIFETIME": timedelta(days=7),
"ROTATE_REFRESH_TOKENS": True,
"BLACKLIST_AFTER_ROTATION": True,
}

**`proxy.ts` (simplified):**
```typescript
async function checkAuth(request: NextRequest) {
  const access = request.cookies.get('access')?.value;
  const refresh = request.cookies.get('refresh')?.value;

  if (access && !isTokenExpired(access)) return null; // let through

  if (refresh) {
    const res = await fetch(`${DJANGO_URL}/api/login/refresh/auto/`, {
      method: 'POST',
      body: JSON.stringify({ refresh }),
    });
    if (res.status === 200) {
      // set new cookies and redirect
    } else {
      return clearCookiesAndRedirect(); // ← this causes logout
    }
  }
}

---

Root Cause

Next.js 16 App Router fires multiple parallel RSC requests on every navigation (layout + page + nested components). When the access token expires at the exact moment of navigation, all of these requests hit proxy.ts simultaneously.

Each sees access cookie missing/expired and attempts to refresh using the same refresh token R1.

With ROTATE_REFRESH_TOKENS=True + BLACKLIST_AFTER_ROTATION=True:

• Request 1: calls Django → Django rotates R1 → returns new tokens → blacklists R1 ✅
• Request 2: calls Django with R1 → Django says "blacklisted" → 401 ❌
• proxy.ts receives 401 → calls clearCookiesAndRedirect() → user logged out

This happens completely transparently to the user — they just see a redirect to the login page.

---

What We Tried (That Didn't Work)

1. In-memory lock in proxy.ts:

const refreshFlights = new Map<string, Promise<...>>();

Seemed logical but did not work — unclear if this is because proxy.ts in Next.js 16 still runs in a context where module-level state isn't reliably shared between parallel requests, or another reason. The 401s continued appearing in Django logs.

2. Redis lock in Django:

if not cache.add(lock_key, '1', timeout=5):
    return JsonResponse({'detail': 'Already refreshing'}, status=429)

Parallel requests arrived faster than Redis could process. Still got 401s. Also added unnecessary complexity to Django.

3. prefetch={false} on Link components:
Reduces some prefetch requests but doesn't stop parallel RSC requests during actual navigation.

---

Current Workaround

Setting BLACKLIST_AFTER_ROTATION=False in Django:

SIMPLE_JWT = {
    "ROTATE_REFRESH_TOKENS": True,
    "BLACKLIST_AFTER_ROTATION": False,  # ← workaround
}

This stops the logout because all 6 parallel refresh requests succeed. The token still rotates on each use. The tradeoff: a stolen refresh token won't be immediately invalidated.

This works but it's a security downgrade we'd prefer to avoid.

---

The Question

How do you properly implement single-flight token refresh in Next.js 16 App Router with a rotating+blacklisting token backend, given that:

1. proxy.ts / middleware fires in parallel for multiple RSC requests
2. Module-level Map lock didn't work in our case
3. Redirecting through an intermediate Route Handler (/api/do-refresh) caused browser permission popups
4. We don't want to add auth validation in every page.tsx (defeats the purpose of the proxy)

Is BLACKLIST_AFTER_ROTATION=False simply the accepted tradeoff for Next.js App Router + rotating tokens? How does NextAuth/Auth.js handle this exact concurrency problem internally?

Any insight appreciated.

### Example

_No response_

[nathanschram]

Yeah, you've identified the race condition correctly - Auth.js acknowledges the same problem in their refresh token rotation docs with no built-in solution yet (Discussion #3940 has been open since 2022).

Your module-level Map approach was on the right track. The key is storing the in-flight Promise itself, not a flag or result - a flag creates a TOCTOU race where parallel requests slip between check and set. Sharing the Promise means all callers await the same fetch:

// proxy.ts
const inflightRefreshes = new Map<string, Promise<Response>>();

async function refreshTokens(refreshToken: string): Promise<Response> {
  const existing = inflightRefreshes.get(refreshToken);
  if (existing) return existing; // all parallel requests share this Promise

  const promise = fetch(`${DJANGO_URL}/api/login/refresh/auto/`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refresh: refreshToken }),
  }).finally(() => {
    inflightRefreshes.delete(refreshToken);
  });

  inflightRefreshes.set(refreshToken, promise);
  return promise;
}

In your checkAuth, replace the direct fetch with await refreshTokens(refresh). All 6 parallel RSC requests hit the Map, but only the first one calls Django.

One caveat - the Next.js docs warn against module-level state in proxy.ts because it can run on CDN/Edge where state doesn't persist. Since you're self-hosting with npm run start, module state persists in the Node.js process - safe for your setup, just wouldn't work on Vercel.

Your BLACKLIST_AFTER_ROTATION=False is reasonable for now. Longer term, you could also refresh proactively a couple of minutes before expiry in proxy.ts - that way navigations never hit the race window at all.

[sloweyyy]

@nathanschram's in-flight Promise deduplication is the correct fix for the immediate race condition. I want to add two things:

Why your Redis lock failed

Your Django-side lock (cache.add) returns 429 for the "losing" requests, but your proxy.ts only handles 200 and treats everything else (including 429) as an auth failure → logout. If you retry the Redis approach, you'd need proxy.ts to retry on 429 after a short delay. But the client-side Promise deduplication is cleaner since it avoids the extra round-trip entirely.

Proactive refresh eliminates the race window entirely

Instead of waiting for the access token to expire and then racing to refresh, refresh it before it expires:

function shouldRefreshProactively(access: string): boolean {
  const payload = JSON.parse(atob(access.split('.')[1]));
  const expiresIn = payload.exp * 1000 - Date.now();
  return expiresIn < 2 * 60 * 1000; // refresh 2 min before expiry
}

async function checkAuth(request: NextRequest) {
  const access = request.cookies.get('access')?.value;
  const refresh = request.cookies.get('refresh')?.value;

  if (access && !isTokenExpired(access) && !shouldRefreshProactively(access)) {
    return null; // valid and not near expiry
  }

  if (access && !isTokenExpired(access)) {
    // Token still valid but expiring soon — refresh in background
    // Even if this fails, the request proceeds with the current token
    refreshTokens(refresh).catch(() => {});
    return null;
  }

  // Token expired — must refresh before proceeding
  if (refresh) {
    const res = await refreshTokens(refresh); // deduped via Map
    // handle response...
  }
}

This way, the refresh happens during normal navigation while the access token is still valid. By the time it actually expires, you already have a new one. The race window effectively disappears.

Combined approach: Use the in-flight Promise deduplication (nathanschram's answer) + proactive refresh. This lets you keep BLACKLIST_AFTER_ROTATION=True safely.

[sefin23]

To summarize the root cause and the best solution path:

Root Cause

Next.js App Router fires parallel RSC requests on navigation (layout + page + nested segments). When the access token expires mid-navigation, all requests hit proxy.ts simultaneously — each sees an expired token and tries to refresh with the same R1 refresh token. With ROTATE_REFRESH_TOKENS=True + BLACKLIST_AFTER_ROTATION=True, only the first refresh succeeds; the rest get 401 (blacklisted token) → logout.

Recommended Solution: In-Flight Promise Deduplication + Proactive Refresh

Combine both approaches for a robust fix:

1. In-Flight Promise Deduplication (fixes the race)

// proxy.ts
const inflightRefreshes = new Map<string, Promise<Response>>();

async function refreshTokens(refreshToken: string): Promise<Response> {
  const existing = inflightRefreshes.get(refreshToken);
  if (existing) return existing; // all parallel requests share the same Promise

  const promise = fetch(`${DJANGO_URL}/api/login/refresh/auto/`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ refresh: refreshToken }),
  }).finally(() => {
    inflightRefreshes.delete(refreshToken);
  });

  inflightRefreshes.set(refreshToken, promise);
  return promise;
}

Storing the Promise itself (not a flag) means all 6 parallel RSC requests await the same Django call — only one refresh hits your backend.

Self-hosting note: Module-level state persists in a Node.js process (npm run start), so this works reliably on your VPS setup. It would not work on Vercel Edge/CDN where each invocation is stateless.

2. Proactive Refresh (eliminates the race window entirely)

function shouldRefreshProactively(access: string): boolean {
  const payload = JSON.parse(atob(access.split('.')[1]));
  const expiresIn = payload.exp * 1000 - Date.now();
  return expiresIn < 2 * 60 * 1000; // refresh 2 min before expiry
}

Trigger a background refresh when the token is still valid but expiring soon. By the time users navigate at the expiry boundary, the new token is already in place — no race to trigger.

Decision Matrix

Approach	Fixes Race	Keeps Blacklisting	Complexity
BLACKLIST_AFTER_ROTATION=False	✅	❌	Low
In-flight Promise dedup	✅	✅	Medium
Proactive refresh only	Mostly ✅	✅	Medium
Both combined	✅✅	✅	Medium

The combined approach (in-flight dedup + proactive refresh) lets you keep BLACKLIST_AFTER_ROTATION=True without the security tradeoff.