P-9 — Session Management Patterns

Combining Both

Most security-conscious systems use both:

• Idle timeout: 30 minutes of inactivity
• Absolute timeout: 24 hours regardless of activity

async function createSession(userId: string) {
  const token = generateSecureToken();
  const key = `session:${token}`;
  const now = Date.now();
 
  await redis.hset(key,
    'userId', userId,
    'createdAt', String(now),
    'lastSeen', String(now),
    'absoluteExpiry', String(now + 86400 * 1000)
  );
  await redis.expire(key, 1800);  // 30-minute idle timeout
 
  return token;
}

---

Multi-Device Session Management

Users log in from multiple devices. Each device gets its own session token. You need to:

• List all active sessions for a user
• Revoke a specific session (logout from one device)
• Revoke all sessions (logout from all devices, e.g., after password change)

Track Sessions per User with a Set

async function createSession(userId: string, deviceInfo: string) {
  const token = generateSecureToken();
  const sessionKey = `session:${token}`;
  const userSessionsKey = `user:sessions:${userId}`;
 
  await redis.hset(sessionKey,
    'userId', userId,
    'device', deviceInfo,
    'createdAt', String(Date.now())
  );
  await redis.expire(sessionKey, 3600);
 
  // Track this session under the user's session index
  await redis.sadd(userSessionsKey, token);
  await redis.expire(userSessionsKey, 3600);  // clean up if user is inactive
 
  return token;
}
 
async function getActiveSessions(userId: string) {
  const tokens = await redis.smembers(`user:sessions:${userId}`);
 
  // Filter out expired sessions (their Hash keys won't exist)
  const sessions = await Promise.all(
    tokens.map(async (token) => {
      const data = await redis.hgetall(`session:${token}`);
      return Object.keys(data).length > 0 ? { token, ...data } : null;
    })
  );
 
  return sessions.filter(Boolean);
}
 
async function revokeSession(userId: string, token: string) {
  await redis.del(`session:${token}`);
  await redis.srem(`user:sessions:${userId}`, token);
}
 
async function revokeAllSessions(userId: string) {
  const tokens = await redis.smembers(`user:sessions:${userId}`);
  if (tokens.length > 0) {
    await redis.del(...tokens.map(t => `session:${t}`));
  }
  await redis.del(`user:sessions:${userId}`);
}

Memory cleanup: The user sessions Set may contain tokens of expired sessions (the session Hash expired but the token remains in the Set). The getActiveSessions function handles this by checking if the Hash exists, but the Set grows over time. Add a periodic cleanup or use SSCAN + EXISTS to prune stale tokens.

---

The Read-from-Replica Consistency Trap

Many Redis setups route read commands to replicas to reduce primary load. Session reads are a common target.

The problem: Replication in Redis is asynchronous. When a session is created or updated on the primary, the change propagates to replicas with a small delay (typically < 1ms, but up to seconds under load or network issues).

If a request is authenticated (session created on primary), and the next request reads the session from a replica before replication completes, the session lookup returns nil — the user appears logged out.

Request 1: POST /login  → session created on PRIMARY (token: abc123)
Response:  Set-Cookie: session=abc123
 
Request 2: GET /profile → reads from REPLICA (replica lag: 50ms)
           HGETALL session:abc123 → {} (not replicated yet)
           → user appears unauthenticated → 401 Unauthorized

Fix: Always read sessions from the primary.

// ioredis: use primary for session operations
const primaryRedis = new Redis({ host: 'redis-primary', port: 6379 });
const replicaRedis = new Redis({ host: 'redis-replica', port: 6379 });
 
// Sessions: always primary
async function getSession(token: string) {
  return primaryRedis.hgetall(`session:${token}`);
}
 
// Non-critical reads: can use replica
async function getProductData(productId: string) {
  return replicaRedis.get(`product:${productId}`);
}

For most session workloads, the primary handles the load comfortably — sessions are a small fraction of total Redis traffic.

---

Session Token Security

This is not Redis-specific, but engineers implementing Redis sessions often get this wrong:

Use a cryptographically secure random token:

import { randomBytes } from 'crypto';
 
function generateSecureToken(): string {
  return randomBytes(32).toString('hex');  // 64 hex characters, 256 bits of entropy
}

Do not use UUIDs (v4 UUIDs are random but some implementations have flaws; 122 bits of entropy vs 256).
Do not use incrementing integers or predictable patterns.
Do not sign session tokens with HMAC and put user data in the token unless you understand session forgery risks.

Set the cookie correctly:

Set-Cookie: session={token}; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

• HttpOnly — JavaScript cannot access the cookie (XSS protection)
• Secure — only sent over HTTPS
• SameSite=Strict — CSRF protection

---

Summary

• Use a Hash for session data — atomic per-field updates, self-documenting, no race conditions
• Idle timeout via EXPIRE on each request; absolute timeout via a stored expiry field
• Multi-device sessions: track token Set per user (user:sessions:{userId}); revoke by DEL session Hash + SREM from Set
• Always read sessions from the primary — replica lag causes silent authentication failures
• Secure tokens: 256-bit cryptographically random, stored in HttpOnly; Secure; SameSite=Strict cookies

Next: P-10 — Connection Pooling and Client Configuration — TCP connection overhead, ioredis pool sizing, reconnection strategies, and health check patterns for production clients.

---