How do you securely handle authentication in SSR? What are the risks of passing tokens via cookies vs headers?

Authentication in Server-Side Rendering (SSR) presents unique challenges because the server needs access to authentication state during the initial page render, before any client-side JavaScript runs. The core requirement is that authentication credentials must be automatically included in HTTP requests made by the server. This fundamental constraint explains why cookie-based authentication dominates SSR architectures: cookies are automatically sent with every HTTP request by the browser, making them accessible in getServerSideProps, middleware, and server components. Header-based authentication (like Authorization: Bearer) fails in SSR because these headers must be manually attached by client-side JavaScript, which hasn't executed during server rendering.

Header-based authentication breaks SSR because the server cannot access tokens stored in localStorage or sessionStorage during the initial render. When a user visits a protected route like /dashboard directly, the sequence of events reveals the problem: the server renders the page without authentication context, sends unauthenticated HTML, client JavaScript loads, reads the token from storage, and finally fetches protected data—causing UI flickering, extra network requests, and a poor user experience. This is why header-based auth with localStorage is fundamentally incompatible with SSR requirements.

Storing authentication tokens in localStorage creates a severe security risk because any XSS vulnerability—even a minor one from a third-party dependency, an npm package compromise, or an inadvertently exposed console—can lead to token theft. The attacker can then impersonate the user indefinitely. HTTP-only cookies prevent this entirely: the cookie is marked with the HttpOnly flag, meaning the browser's JavaScript engine cannot access it at all. Even if an attacker injects malicious scripts, they cannot read the authentication token. This is why security experts universally recommend HTTP-only cookies for session management in production applications.

While cookies solve XSS and SSR problems, they introduce CSRF (Cross-Site Request Forgery) risks. However, modern browsers provide robust CSRF protection through the SameSite cookie attribute. Setting SameSite=strict or sameSite=lax prevents cookies from being sent with cross-site requests, effectively neutralizing CSRF attacks. For additional protection, many applications implement CSRF tokens or use the double-submit cookie pattern as NextAuth.js does. The OWASP Foundation documents these patterns as secure practices for cookie-based authentication.

For optimal security and user experience, implement the silent refresh pattern: short-lived access tokens (5-15 minutes) stored in HTTP-only cookies, with refresh tokens for obtaining new access tokens. The access token is automatically sent with every request via cookies. When it expires, the server can use the refresh token (also HTTP-only) to issue a new access token transparently. This minimizes the window of compromise if a token is stolen while maintaining seamless UX. The refresh token itself should be rotated and invalidated after use to prevent replay attacks.