Session authentication

Backend Fundamentals · Backend Security · 8 min read

1. What problem does this solve?

Motivation
When a user logs in, the backend must remember who that user is on subsequent requests. Without a mechanism to persist that identity across stateless HTTP calls, every request would require the user to re‑authenticate, which is impractical for real applications.

What problem exists

• HTTP is stateless: each request is independent.
• Clients (browsers, mobile apps) need a way to prove their identity without sending credentials every time.
• The server must associate a request with a user session securely.

Why the problem matters

• User experience: Re‑authenticating on every request would be annoying.
• Security: Storing credentials on the client is risky; the server must verify identity without exposing secrets.
• Scalability: In a distributed system, the session data must be accessible to any instance handling a request.

What happens if this concept is not used

• Users would be forced to log in repeatedly.
• The server would need to store sensitive data in the client or in insecure cookies.
• The system would be vulnerable to replay attacks, session hijacking, and other credential‑based attacks.

Where this concept appears in real backend systems

• Web applications (e.g., e‑commerce sites, SaaS dashboards).
• Mobile backends that issue tokens to apps.
• Microservice architectures where an auth gateway issues session tokens that downstream services validate.

2. Mental model

Analogy
Think of a library card.

• You visit the library and show your ID; the librarian checks it and gives you a card.
• The card is a session token: it proves you’re a registered user without carrying your ID every time.
• When you return, you show the card; the librarian verifies it and lets you borrow books.

Engineering model

• Login → Generate a session identifier (token).
• Store the identifier in a secure, tamper‑proof place (cookie, HTTP‑Only, signed).
• Validate the identifier on every request to map it back to the user’s data.
• Expire or invalidate the session when needed.

3. Deep explanation

Internals

• Session ID: a random, cryptographically secure string (e.g., UUID v4, JWT ID).
• Session store: a backend (in‑memory, Redis, database) that maps the ID to user data and metadata (expiry, device).
• Cookie: the client stores the ID in an HTTP‑Only, Secure cookie (or in localStorage for SPAs, but cookies are safer).
• Token: sometimes the session ID is encoded as a JWT (JSON Web Token) that contains claims and can be verified without a store.

Important terminology

Trade‑offs

Failure modes

• Token theft: if cookie is stolen, attacker can impersonate. Mitigate with HttpOnly, Secure, SameSite, short expiry.
• Store outage: if Redis is down, sessions cannot be validated. Use fallback or graceful degradation.
• Replay attacks: same token reused. Mitigate with nonce or short TTL.
• Token rotation: failing to rotate refresh tokens can lead to long‑lived sessions.

Limitations

• Stateless JWT: cannot store server‑side state (e.g., logout).
• Server‑side store: requires scaling the store (sharding, clustering).
• Cookie‑based: limited to browsers; native apps often use bearer tokens.

Where it fits in a backend architecture

┌───────────────┐
│  Client (Web) │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │
        ▼
┌───────────────┐
│ Auth Service  │  ← Session store (Redis)
└───────┬───────┘
        │
        ▼
┌───────────────┐
│  Microservices│  ← Validate session token
└───────────────┘

Interaction with related concepts

• OAuth2: uses access/refresh tokens; session auth is a simpler alternative for internal services.
• Rate limiting: often keyed by session ID.
• Audit logs: session IDs help correlate actions.
• CORS: SameSite cookies affect cross‑origin requests.

4. How it works

1. User logs in → server verifies credentials.
2. Generate session ID (e.g., UUID v4).
3. Store session in Redis: session:{id} → {userId, expiresAt, device}.
4. Set cookie: Set-Cookie: session_id=<id>; HttpOnly; Secure; SameSite=Strict; Expires=<expires>.
5. Client sends request → cookie automatically included.
6. API Gateway forwards request to Auth Service.
7. Auth Service reads cookie, looks up session in Redis.
8. Validate: check expiry, existence.
9. Attach user context to request (e.g., req.user).
10. Proceed to business logic.
11. Logout → delete session from Redis, clear cookie.

sequenceDiagram
    participant U as User
    participant C as Client
    participant G as API Gateway
    participant A as Auth Service
    participant R as Redis

    U->>C: POST /login (credentials)
    C->>G: /login
    G->>A: /login
    A->>R: SET session:{id} = {userId, expires}
    A->>C: Set-Cookie: session_id=<id>; HttpOnly; Secure; SameSite=Strict
    U->>C: GET /profile
    C->>G: /profile (cookie sent)
    G->>A: /profile
    A->>R: GET session:{id}
    A->>C: 200 OK (with user data)

5. Practical implementation

TypeScript/Node.js example (Express + Redis)

// src/auth/session.ts
import { Request, Response, NextFunction } from 'express';
import { v4 as uuidv4 } from 'uuid';
import { createClient } from 'redis';
import cookieParser from 'cookie-parser';

const redis = createClient(); // default localhost:6379
redis.on('error', console.error);
await redis.connect();

const SESSION_COOKIE = 'session_id';
const SESSION_TTL = 60 * 60 * 24; // 24h

export async function loginHandler(req: Request, res: Response) {
  const { email, password } = req.body;

  // 1️⃣ Verify credentials (pseudo)
  const user = await findUserByEmail(email);
  if (!user || !await comparePassword(password, user.hash)) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }

  // 2️⃣ Create session ID
  const sid = uuidv4();

  // 3️⃣ Store session in Redis
  await redis.set(`session:${sid}`, JSON.stringify({
    userId: user.id,
    expiresAt: Date.now() + SESSION_TTL * 1000,
  }), {
    EX: SESSION_TTL,
  });

  // 4️⃣ Set secure cookie
  res.cookie(SESSION_COOKIE, sid, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'strict',
    maxAge: SESSION_TTL * 1000,
  });

  res.json({ message: 'Logged in' });
}

export async function authMiddleware(req: Request, res: Response, next: NextFunction) {
  const sid = req.cookies[SESSION_COOKIE];
  if (!sid) return res.status(401).json({ error: 'No session' });

  const data = await redis.get(`session:${sid}`);
  if (!data) return res.status(401).json({ error: 'Invalid session' });

  const session = JSON.parse(data);
  if (session.expiresAt < Date.now()) {
    await redis.del(`session:${sid}`);
    return res.status(401).json({ error: 'Session expired' });
  }

  // Attach user context
  req.user = { id: session.userId };
  next();
}

export async function logoutHandler(req: Request, res: Response) {
  const sid = req.cookies[SESSION_COOKIE];
  if (sid) {
    await redis.del(`session:${sid}`);
    res.clearCookie(SESSION_COOKIE);
  }
  res.json({ message: 'Logged out' });
}

Key lines explained

• redis.set(..., { EX: SESSION_TTL }): sets TTL so Redis auto‑expires the key.
• res.cookie(..., { httpOnly, secure, sameSite }): protects against XSS and CSRF.
• authMiddleware: central place to validate session on every protected route.

FastAPI (Python) example (JWT)

# auth.py
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordBearer
import jwt, datetime

app = FastAPI()
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token")

SECRET_KEY = "super-secret"  # in env
ALGORITHM = "HS256"

def create_access_token(data: dict, expires_delta: int = 3600):
    to_encode = data.copy()
    to_encode.update({"exp": datetime.datetime.utcnow() + datetime.timedelta(seconds=expires_delta)})
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

@app.post("/token")
async def login(form_data: OAuth2PasswordRequestForm = Depends()):
    # verify user...
    access_token = create_access_token({"sub": user.id})
    return {"access_token": access_token, "token_type": "bearer"}

async def get_current_user(token: str = Depends(oauth2_scheme)):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
        user_id: str = payload.get("sub")
        if user_id is None:
            raise HTTPException(status_code=401)
    except jwt.PyJWTError:
        raise HTTPException(status_code=401)
    return {"id": user_id}

6. Production considerations

7. Common mistakes

8. Senior engineer perspective

Architecture decisions

• Store choice: Redis vs. database vs. JWT. Consider read/write patterns, consistency, and revocation needs.
• Session granularity: per device vs. global.
• Token format: opaque ID vs. signed JWT.
• Refresh strategy: short‑lived access + long‑lived refresh.

Trade‑offs

• Stateless JWT: great for horizontal scaling, but hard to revoke.
• Server‑side store: revocable, but adds a network hop and a single point of failure.

Bottlenecks

• Redis hot spot: many requests to the same key (e.g., admin session). Use sharding or separate keys.
• Network latency: session lookup can dominate request time; mitigate with local caching.

Failure scenarios

• Store outage: fallback to JWT or deny access.
• Token replay: mitigate with nonce or short TTL.

Monitoring

• Session count per user: detect abnormal spikes.
• TTL hit rate: high eviction may indicate memory pressure.
• Latency of session lookup: track per endpoint.

Cost/performance

• Redis memory: each session ~200B; 1M sessions ≈ 200MB.
• Network: each request adds a round‑trip to Redis; consider using redis-multi or pipeline.

When NOT to use

• Highly dynamic data that must be invalidated immediately (e.g., banking). Use short‑lived JWT + server‑side revocation.
• Low‑traffic, simple apps: a stateless JWT may be sufficient.

9. Interview questions

10. Hands‑on task

Task: Add a “Remember Me” feature to the existing login flow.

1. Add a checkbox to the login form.
2. If checked, set the session cookie’s maxAge to 30 days instead of 24h.
3. Store a flag in Redis (remember:true) and enforce a stricter CSRF policy for long‑lived sessions.
4. Write unit tests that verify the cookie’s maxAge and that the session is invalidated after 30 days.

11. Quick revision

• Session authentication maps a request to a user without re‑authenticating each time.
• Store session ID in an HttpOnly, Secure cookie (SameSite=Strict).
• Use a fast, distributed store (Redis) or signed JWTs.
• TTLs keep sessions short; rotate IDs on privilege changes.
• Revocation is trivial with server‑side stores; hard with JWTs.
• Protect against XSS, CSRF, replay, and store outages.
• Monitor session count, lookup latency, and eviction rates.
• Common pitfalls: insecure cookies, long‑lived tokens, missing logout cleanup.

12. References

• RFC 6265 – HTTP State Management Mechanism
• OWASP Session Management Cheat Sheet
• Node.js Express Cookie Parser
• Redis Session Store
• JWT Specification (RFC 7519)
• FastAPI Security
• Next.js API Routes