Server-side rendering auth bugs in real login flows

Why the app works in demos but fails after login

Most demo builds use one account, one browser, and a clean local setup. That hides the messy part: real users arrive with different cookies, expired sessions, stale tabs, shared devices, and pages that pass through caches you did not notice during development.

A React app can look perfect in a demo because the server keeps rendering the same safe state. You log in once, click around, and everything matches. Then the app goes live, and each request starts to matter. Server-side rendering reads the request in front of it, not the happy-path state you tested five minutes ago.

That is where server-side rendering auth bugs show up. The server may render HTML for a user who has a valid cookie, while the browser still loads old client state. Or a cache may store a private response and hand it to the next visitor. The result feels random to users, but it usually comes from one simple mistake: the app treated a personal request like a public page.

Teams often miss this because fake auth is too clean. A local demo might use a hardcoded user, a dev token, or a login flow that never expires. Nothing changes between requests, so SSR looks stable. Real auth changes on every request. Cookies can be missing, rotated, scoped to the wrong domain, or blocked in one environment and accepted in another.

A small example makes the pain obvious. User A logs in and opens a dashboard. The server renders their name into the page. A cache keeps that HTML for a minute. User B visits the same route and briefly sees User A's dashboard before the app corrects itself, or worse, never corrects it at all.

That is why these bugs feel embarrassing. The app worked in staging, the demo impressed everyone, and then the first real login exposed that the page was never truly request-aware.

What real auth changes in an SSR app

A React app feels easy before login exists. The browser loads a page, React starts, and local state decides what to show. Real auth changes that order.

With SSR, the server makes the first decision. It reads cookies and headers before React runs, so the first HTML already depends on the incoming request. If the request says "this user has a valid session," the server may render a dashboard. If not, it may render a sign-in page.

That sounds obvious, but many teams still think about auth as a client-side flag. That works in a demo. It breaks on protected pages, because the browser is no longer the first source of truth. A page is private only when the server checks the request and renders the right result before hydration starts.

A simple example shows the shift. A user signs in, then opens /account in a new tab. The server receives the cookie first, not your React context, so it must decide what /account means for that user on its own. If your app depends on local state to "confirm" login later, the first render can be wrong.

Token refresh adds another moving part. A request can start with an expired access token, refresh it on the server, and finish with a different auth state than it had a few milliseconds earlier. If one part of your code reads auth before the refresh and another part reads it after, the same page can disagree with itself.

Logout has the same problem in reverse. Deleting a token in the browser is not enough if the server still trusts an old cookie, an old session record, or stale request assumptions. Users notice this fast when they log out, hit Back, and briefly see private content again.

In practice, auth state in an SSR app lives in more than one place:

• the incoming cookie
• the server session or token check
• any refresh that happens during the request
• the client state React picks up after hydration

When those copies drift apart, you get the bugs that never showed up in a demo: the wrong first render, a flash of logged-out UI, or a page that changes identity after load.

A simple failure story

A team ships a React app that looks fine in demos. The home page renders on the server, the login form works, and the dashboard loads in local testing. Then real users sign in, refresh once, and the odd behavior starts. This is the kind of server-side rendering auth bugs that stays hidden until cookies, caching, and real traffic meet.

A user logs in and opens the dashboard. The browser stores the auth cookie, but the next request hits a server cache that still holds an older guest version of /dashboard. The server sends HTML with a "Sign in" button, public navigation, and empty dashboard content.

A moment later, React runs in the browser, reads the fresh session, calls the user API, and gets the real account data. Now the page flips. The guest menu changes to the user menu. Empty boxes turn into private data. The user sees a flicker and wonders if the app signed them out.

Then someone clicks a protected tab. The server still treats the request like a guest request and redirects to /login. The client already knows the user is signed in, so it pushes back to /dashboard. The browser bounces between both pages, and the user gets stuck in a redirect loop.

Nothing is wrong with the password. Nothing is wrong with the session itself. The first HTML is wrong, and the client corrects it too late. That gap is enough to break trust.

This kind of bug feels small when engineers test with one account on localhost. It feels much bigger on a customer call. A founder logs in, sees "Create account" in the header for half a second, clicks a dashboard link, and lands back on the login page. The app did authenticate the user. It just rendered two different truths in the same visit.

How to debug it step by step

Start with one request and follow it all the way to the browser. Auth bugs in SSR often look random, but they usually come from one disagreement: the server thinks the user is in one state, and the client thinks something else.

On the server, log the request path, whether a session cookie is present, and what user state the server resolved before it renders HTML. Do not log raw tokens or full cookie values. A simple "cookie present / no cookie" and "user id resolved / no user" is enough to tell you where the state changed.

Then log the client auth state before hydration finishes and again on the first render after hydration. If the server rendered a signed-in page but the browser starts as signed out for a moment, you have a hydration auth mismatch. If both sides start signed out even though the cookie exists, the problem is earlier, often in cookie parsing or server session lookup.

Compare what the server sent

Do not trust the final DOM in devtools right away. Check the raw HTML the server returned and compare it with the first client state. If the HTML already contains the wrong navbar, username, or public page shell, the bug happened on the server. If the HTML is correct and the browser flips it after load, the bug is in client state, hydration, or a late auth check.

Use the same short test flow every time so you can compare results:

• Log in and land on a protected page
• Refresh the page with a full reload
• Log out and refresh again
• Press the back button and see what appears first

After that, repeat the exact flow with two different users in two separate browser profiles. This step catches cache leaks fast. If user B ever sees user A's name, dashboard shell, or account menu, even for a second, you likely cached private HTML or reused auth state across requests.

Make the bug small enough to see

A small failure story helps. Say user A logs in, loads "/dashboard", logs out, then user B logs in on the same machine. If user B gets a flash of A's dashboard before the page corrects itself, save the server logs for both requests and compare them next to the raw HTML. That single comparison often exposes the exact break in server-side rendering auth bugs.

When you debug this way, you stop guessing. You can point to the request, the cookie, the HTML, and the first client state, then fix the part that actually disagrees.

Cache mistakes that mix public and private pages

Cache bugs often look like auth bugs. A user logs in, refreshes, and sees someone else's name in the header. Or they log out and still get the account page for one more request. The login code may be fine. The cache is what broke the page.

The first mistake is simple: teams cache by URL and forget that auth changes the response. If /dashboard or even / renders different HTML for signed-in users, the cache key cannot stop at the path. A shared cache that stores "GET /" once can hand a private version of that page to the next visitor.

A small example makes this obvious. User A signs in and opens the home page. The server renders "Welcome back, Maya" and stores that HTML in a CDN or reverse proxy cache under /. User B, who is not signed in, requests / a few seconds later and gets Maya's version. That is not a login failure. That is a bad cache boundary.

Server fetch caches can cause the same leak even when the page HTML itself is not cached. Many SSR apps keep an in-memory map, a singleton API client, or a framework-level fetch cache that survives across requests. If that cache stores the result of /api/me or /api/account without tying it to the current user, request B can reuse data from request A.

Missing vary rules make this worse. If the response changes when the Cookie header changes, the cache needs to know that. Otherwise, a proxy sees two requests for the same URL and assumes the response is the same. In practice, that means your "logged out" and "logged in" versions fight each other.

Prefetching adds another trap. A public page may prefetch account data on hover, on idle, or during route warm-up. If that prefetched result lands in a shared cache with a generic name, the public page can later reuse private data by accident.

A short audit catches most of this:

• Check every cached SSR response that changes with auth state.
• Check every fetch to /me, session, profile, or account endpoints.
• Check whether your proxy varies on cookies or skips caching private pages.
• Check prefetch code that runs before auth state is fully known.

Start with one rule: if HTML or JSON depends on who the user is, do not let a shared cache treat those requests as identical.

Cookie mistakes that break the first render

A lot of SSR auth bugs start with one bad assumption: "the browser will tell us who the user is." On the first render, the server builds the page before your client code runs. If your auth check lives in useEffect, reads document.cookie, or waits for a browser store, the server sends guest HTML even though the user already has a valid session.

That gap shows up fast on real routes like /account or /billing. A user signs in, reloads, and sees the logged-out header for a moment. Then React hydrates, reads the cookie in the browser, and flips the page. People call it a hydration bug, but the root cause is usually cookie handling.

A small example makes this obvious. A user logs in on app.example.com, then opens a protected page on another route group. The auth cookie exists, but its path is /app, so the browser never sends it for /settings. The server cannot see the session, so it renders a public page. The user thinks login "didn't stick," even though the cookie is still there.

Path and domain mistakes cause more trouble than teams expect. If one service sets a cookie for a subdomain and another route expects it on the parent domain, requests arrive without auth. The app looks random because some pages work and others do not.

Token refresh can create the same mess. If the server renders with an expired token and your refresh starts only after hydration, the first HTML is wrong by design. The page loads as logged out, then changes a second later. That is not a React problem. It is a request timing problem.

Logout bugs can linger for days. Teams often clear one cookie and forget another, such as a refresh token, a session marker, or an old legacy cookie. Then one part of the app thinks the user signed out while another silently creates a new session.

Check four things on every auth request:

• which cookies the server receives
• each cookie's domain and path
• whether the server can refresh before rendering
• whether logout deletes every auth-related cookie

If those four line up, the first render usually stops lying.

Hydration mistakes after the page loads

A lot of auth bugs start after the HTML already looks fine. The server sends a signed-out shell, then the browser restores a signed-in user from a cookie, local storage, or an API call. For a moment, the app believes two different things at once.

That gap creates a classic hydration auth mismatch. The navbar says "Sign in" on first paint, then flips to the user menu a split second later. Sometimes it gets worse: the server rendered a public route, but the client store wakes up with a valid session and tries to push the user somewhere else.

Route guards often make this mess bigger. One guard runs on the server and decides "guest." Another runs on the client, sees the restored user, and redirects again. The user lands on the right page, then gets bounced to login, then back, or ends up with a blank screen because two redirects race each other.

Loading states can hide the problem without fixing it. Teams add a full-page spinner until auth finishes, and the flicker goes away. The bug still exists. The app still renders different trees on the server and client, and that mismatch can break forms, menus, and any code that depends on the first render.

A simple example looks like this:

• The server cannot read the session correctly, so it renders a guest header.
• The client bootstraps, reads a valid token, and fills the user store.
• A client-only guard redirects to "/dashboard".
• Another effect checks stale auth state and redirects back to "/login".

Fix the source of truth first. If the server can read the same auth data as the client, render from that shared state on the first request. If you cannot do that yet, delay route decisions until auth is resolved once, in one place, not in three components.

Also check your defaults. An auth store that starts as isAuthenticated: false will often cause server-side rendering auth bugs even when the session is valid. A better default is "unknown" so the app waits for a real answer before it redirects.

When a React app leaves the demo stage, these bugs show up fast. Real users reload pages, open multiple tabs, and return with half-expired sessions. If the first render and the hydrated state disagree, the app feels unreliable even when login itself works.

Common traps teams miss in staging

Staging often feels close to production, but it still hides some of the ugliest server-side rendering auth bugs. The usual reason is simple: the test setup is too neat. Real users arrive with old cookies, half-finished sessions, different browsers, and requests that hit different servers.

One shared test account hides a lot. If everyone logs in with the same user, you never see what happens when user A's cached page leaks into user B's first render, or when role-based content changes the HTML on the server but not in the browser.

Warm caches also make bad code look fine. After a few clean test runs, your staging server may keep the right data in memory, reuse rendered output, or skip the slow path that a new user hits first. Local runs can look even cleaner because you test after your own login flow has already set every cookie the app expects.

Mock auth is another trap. It gets you through the happy path, but it skips the messy parts that break real apps: expired sessions, refresh tokens, missing claims, clock drift, and the short window where the server sees an old cookie while the browser has already refreshed it. That gap is where hydration auth mismatch starts to show up.

A small setup change can also flip cookie behavior. A staging proxy might rewrite headers. One region might terminate TLS differently. A subdomain change can break SameSite, Secure, Domain, or Path rules even when the app code stays the same. Then the first SSR request arrives without the cookie you thought you had.

A staging check should look more like this:

• Use at least two users with different roles and fresh sessions.
• Test after clearing cookies, local storage, and CDN cache.
• Let sessions expire, then reload a protected page.
• Run the same flow through the real proxy and from another region.

If staging only proves that one account can log in on a warm server, it proves almost nothing. The bugs usually show up on the first cold request, with the wrong cookie, for the wrong user, behind the wrong edge layer.

Quick checks before you ship

Many server-side rendering auth bugs stay hidden until someone uses the app like a real person, not like a developer with one warm browser tab and a fresh token. A five minute check before release can catch the stuff that creates the worst support tickets.

Run these checks with production-like cache settings, real cookies, and browser devtools open. If you only test client-side navigation, you will miss the first render problems that users hit after login, logout, or session expiry.

• Refresh a protected page by typing the URL directly into the address bar. The server should render the right state on the first response, not show a guest page and then flip after hydration.
• Open a guest session and a logged-in session side by side. Use separate browser profiles or an incognito window. If one session leaks into the other, shared cache or loose cookie handling is usually the cause.
• Expire a token while moving through the app. Click to a new page after the session dies. Watch whether the server redirects cleanly, shows stale private data, or gets stuck in a redirect loop.
• Log out, then press the back button. A protected page should not reappear from browser history as if the session still exists. If it does, check cache headers and how the app revalidates auth on restore.
• Check response headers on public and private pages. Look for cache rules, cookie attributes, vary behavior, and anything that lets a shared cache reuse the wrong HTML for the wrong user.

A small example makes the risk obvious. User A logs in and opens their dashboard. User B opens the same route as a guest on the same network edge a minute later. If the HTML response was cached without the right rules, User B may see a page shaped for User A before the app corrects itself. Even a one second flash is bad.

If this checklist finds one bug, assume there are two more nearby. Real login flow debugging gets much easier when you treat the first server response as the thing to test, not just the React app after it wakes up.

What to fix first in your codebase

Most server-side rendering auth bugs keep coming back for one reason: the app has more than one source of truth. The browser thinks one thing, the server thinks another, and your cache may keep a third version alive for a few seconds. That is enough to break the first render.

Start with cache rules. Any page that shows account data, user menus, billing details, or team content should return cache headers that keep shared caches out of the way. In practice, that usually means private or no-store. If a dashboard page gets cached once for Alice, Bob should never have a chance to see that version on his first request.

Then fix where auth truth lives. For SSR, the incoming request is the truth. Read the cookie or session from that request and decide the page state there. Do not let local storage, a stale client store, or a delayed refresh call decide whether the server renders "signed in" or "guest".

The server and client also need to render the same auth shape. If the server sends user: null but the client instantly swaps to a full user object before hydration settles, React will complain, and the page may flicker or attach handlers to the wrong markup. Pick one stable shape and keep it boring. For example, render user, null, or a clear loading state in both places.

Write the rules down. Teams often keep auth behavior in people's heads, and that is where bugs hide. A short checklist helps:

• What happens right after login?
• When do you refresh an expired session?
• What does logout clear on the server and in the browser?
• Which pages can cache, and which pages cannot?
• What should the first SSR render show if auth is uncertain?

That document saves time because edge cases stop turning into debates.

If these bugs keep returning, a short outside review helps. Oleg Sotnikov does Fractional CTO work focused on AI-first development, infrastructure, and production systems, and a quick review of your auth, cache, and SSR setup can spot the mismatch faster than another week of patching.