Authentication Tokens and the Data Layer

The plain-language idea

This lesson assumes the mechanics of tokens and sessions are already familiar — this platform's frontend-practices coverage goes through JWTs versus sessions in depth, and that reasoning isn't repeated here. What's covered here instead is narrower and more code-shaped: once a token exists, how does the code that actually fetches data attach it, and what happens when it expires in the middle of a session with real requests in flight?

Two concrete problems live in the fetching layer specifically:

• Attaching the token consistently. Every authenticated request needs the token attached the same way, every time. Doing that by hand at each individual call site is a real, common source of a specific, confusing bug: one endpoint starts failing with a 401 not because anything is actually wrong with authentication, but because whoever wrote that one call site forgot to add the header. The practical fix is centralizing attachment in one place — a shared fetch wrapper or interceptor that every request goes through, so there is exactly one place the header gets added and exactly one place to fix if it's ever wrong.
• Refreshing an expired access token without racing yourself. An access token eventually expires mid-session, and a refresh token is used to get a new one. The genuinely tricky part isn't the refresh call itself, it's what happens when several requests are in flight, or fire, at the same moment the token expires.

See it in a real thing: a shared fetch wrapper with a single in-flight refresh

let accessToken: string | null = getStoredAccessToken();
let refreshPromise: Promise<string> | null = null;

async function refreshAccessToken(): Promise<string> {
  // If a refresh is already underway, every caller awaits that same
  // promise instead of starting a second, independent refresh request.
  if (!refreshPromise) {
    refreshPromise = fetch("/api/auth/refresh", { method: "POST", credentials: "include" })
      .then((res) => {
        if (!res.ok) throw new Error("Refresh failed");
        return res.json();
      })
      .then((data) => {
        accessToken = data.accessToken;
        return data.accessToken as string;
      })
      .finally(() => {
        refreshPromise = null; // clear it so the next expiry starts a fresh refresh
      });
  }
  return refreshPromise;
}

async function apiFetch(path: string, options: RequestInit = {}): Promise<Response> {
  const withAuth = (token: string | null): RequestInit => ({
    ...options,
    headers: { ...options.headers, ...(token ? { Authorization: `Bearer ${token}` } : {}) },
  });

  let res = await fetch(path, withAuth(accessToken));

  if (res.status === 401) {
    const newToken = await refreshAccessToken();
    res = await fetch(path, withAuth(newToken));
  }

  return res;
}

Every call site just calls apiFetch, so the header is attached the same way everywhere and no individual caller can forget it. The important detail is refreshPromise: if three requests all hit a 401 within the same tick because the access token expired, all three call refreshAccessToken, but only the first one actually starts a new refresh request — the other two await the exact same in-flight promise and reuse its result.

What people usually miss

Watch out

• Manually adding the auth header at each call site doesn't scale. It works until exactly one call site is written without it, and the resulting failure (a lone endpoint returning 401) looks like an authentication bug rather than a missed header.
• A 401 doesn't always mean "log the user out." It might mean "this specific token just expired" — a refresh-and-retry, as shown above, resolves it without disturbing the user at all. Treating every 401 as a hard logout is a common overreaction.
• Concurrent refresh attempts are a real race condition, not a theoretical edge case. Any page that fires more than one authenticated request at once (which is most real pages) can hit multiple 401s in the same instant the moment a token expires mid-session.
• A single shared in-flight promise is the actual fix, not a queue or a lock. Every request that hits a 401 while a refresh is already underway should await that same promise, not start its own refresh or block on a separate synchronization mechanism.
• Reusing an already-invalidated refresh token is a real failure mode, not a hypothetical — some refresh flows consume the refresh token on use, so a second concurrent attempt with the same token fails, which is exactly what the shared promise pattern avoids.

Why this matters in interviews

"How does your app handle a token expiring while multiple requests are in flight?" is a specific, practical question that separates candidates who've only described token mechanics from those who've actually hit and fixed the concurrent-refresh race condition.