ML
← Insights

authentication · software-engineering

Understanding Web Authentication: Sessions vs Tokens, Cookies vs LocalStorage

This guide explores the differences between session-based and token-based authentication, including detailed comparisons of storage mechanisms like cookies and localStorage. It covers best practices for securing web authentication, explains JWT and refresh token usage, introduces two-factor authentication, and outlines how modern standards like OAuth 2.0 fit into stateless authentication models. Ideal for developers and architects building secure, scalable web applications.

·4 min read

Introduction

Authentication is fundamental to securing modern web applications. Developers often choose between session-based and token-based approaches, depending on their app architecture and scalability needs. This guide explores these two models, compares storage options, explains common pitfalls, and provides best practices for implementation.

1. Session-Based Authentication

Overview

  • Client-side: Stores a session identifier in a cookie.
  • Server-side: Tracks session state using memory, disk, or external stores like Redis.

Common Issues

  • Memory Overhead: The server must manage growing session state as more users authenticate. While external stores reduce memory usage, they increase I/O and network load.

  • Scalability: Synchronizing sessions across a distributed server environment introduces complexity and potential bottlenecks.

  • Cross-Domain Limitations: Session cookies are bound to a single domain and cannot easily be shared between subdomains or different origins.

  • Security Risks: Sessions are vulnerable to:

    • XSS (Cross-Site Scripting) – attackers can steal cookies.
    • CSRF (Cross-Site Request Forgery) – malicious sites trick browsers into making authenticated requests.

Mitigation strategies include setting the HttpOnly, Secure, and SameSite flags on cookies and using CSRF tokens.

2. Token-Based Authentication (Stateless)

Overview

  • Client-side: Stores access tokens in localStorage or cookies.
  • Server-side: Verifies the token on each request without tracking session state.

This model is scalable and well-suited for modern SPAs and microservices.

Advantages

  • Stateless architecture reduces backend load.
  • Easily supports horizontal scaling across services or servers.
  • Decouples authentication from server memory or persistence.

JSON Web Tokens (JWTs)

A JWT consists of three base64-encoded parts:

<Header>.<Payload>.<Signature>

Example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJ1c2VySWQiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNjQzNTY4MjQwfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
  • Header: Defines algorithm (e.g., HS256).
  • Payload: Contains claims like userId, exp, scope.
  • Signature: Verifies token integrity.

Note: JWTs are base64-encoded, not encrypted. Anyone with access to a JWT can read its contents unless encryption (JWE) is used.

Refresh Tokens

Refresh tokens enable the issuance of new access tokens without re-authentication.

Best practices:

  • Store securely in httpOnly, Secure cookies.
  • Rotate and expire refresh tokens after use or inactivity.
  • Maintain a revocation list for stolen or expired tokens.

3. Two-Factor Authentication (2FA)

2FA enhances security by requiring a second factor beyond the password.

Flow

  1. User enters username and password.

  2. Server prompts for a second factor:

    • OTP via SMS/email
    • TOTP from an authenticator app
    • Hardware-generated PIN (e.g., YubiKey)

  3. Upon successful validation, the user receives an access token or session.

4. Local Storage vs Cookies

Local Storage

Pros

  • Not sent with every request → immune to CSRF.
  • Simple JavaScript API (localStorage.getItem()).
  • Larger storage limit (~5–10MB).

Cons

  • Vulnerable to XSS (JavaScript-accessible).
  • No built-in expiry or invalidation.
  • Cannot be used in SSR (data unavailable at initial request).
  • Manual logic needed to attach tokens to each request.

Cookies

Pros

  • Automatically sent with each HTTP request.
  • Works well with server-side rendering (SSR).
  • Supports HttpOnly, Secure, SameSite flags for security.
  • Built-in expiration support.
  • Domain/path scoping.

Cons

  • Vulnerable to CSRF unless mitigated.
  • Harder to parse manually in JS.
  • Limited in storage capacity (~4KB total).

5. Secure Cookie Configuration

Use proper flags when setting cookies:

Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Expires=Wed, 01 Jan 2030 00:00:00 GMT
  • HttpOnly: Not accessible via JavaScript.
  • Secure: Only sent over HTTPS.
  • SameSite=Strict: Blocks cross-site requests.
  • Path/Domain: Scopes the cookie.

6. OAuth 2.0 and OpenID Connect

Token-based systems often leverage OAuth 2.0 and OpenID Connect.

Common Flows

  • Authorization Code Flow (with PKCE): For SPAs and mobile apps.
  • Client Credentials Flow: For machine-to-machine APIs.
  • Refresh Token Flow: For long-lived sessions.

These protocols provide a standardized, secure way to authenticate users across platforms.

7. Best Practices

Area Recommendation
Token storage Use httpOnly cookies, avoid localStorage for secrets
Access token expiration Use short-lived tokens (5–15 mins)
Refresh token security Store securely, rotate frequently
CSRF mitigation Use SameSite cookies or CSRF tokens
XSS prevention Sanitize inputs and use a strong Content Security Policy
Cookie security Always use Secure, HttpOnly, and SameSite flags
JWT validation Verify signature and expiration on every request

8. Real-World Examples

  • Google: Uses OAuth 2.0 and httpOnly cookies for refresh tokens.
  • GitHub: Uses personal access tokens and OAuth apps.
  • AWS: Uses temporary credentials managed via session tokens and federated roles.

9. Conclusion

Choosing the right authentication strategy depends on your app’s architecture, scale, and user experience goals:

  • Use sessions for traditional SSR apps with centralized state.
  • Use tokens (JWT) for SPAs, mobile apps, and scalable APIs.
  • Prefer cookies (with HttpOnly) for security-critical tokens.
  • Store refresh tokens securely and manage revocation or rotation.
  • Layer with 2FA for improved account protection.
  • Always implement CSRF and XSS defenses regardless of the method.

Security is a continuous effort—design defensively, monitor actively, and adapt quickly.