JWT Multi-Device Session Management, Invalidation & Security

In modern distributed web and mobile applications, users stay logged in concurrently across multiple devices (e.g. iPhone, MacBook, iPad, work desktop). While stateless JWT Access Tokens (5–15 minute TTL) provide zero-database-lookup performance, managing multi-device lifecycles introduces complex architectural challenges:

• Isolated Single-Device Logout: How do you log a user out of their mobile phone without terminating their active desktop or tablet sessions?
• Global Multi-Device Logout ("Sign Out Everywhere"): How do you terminate all active devices simultaneously without leaving a 15-minute access token window?
• Password Updates: How do you allow a user to update their password while selectively choosing to remain logged in on the current device?
• Account Locked / Suspended: How do admins or anti-fraud systems lock an account and achieve 0-millisecond revocation across all microservices?
• Token Theft & Account Compromise: How do you detect when a hacker replays a stolen refresh token and automatically quarantine the account?

---

Interactive Multi-Device Lifecycle Simulator

The simulator below demonstrates how session states, Redis caches, token versions, and database records react across multiple devices during Single-Device Logout, Global Logout, Account Lock, and Token Theft Detection:

Multi-Device JWT Lifecycle & Session Invalidation EngineInteractive Simulator

User Devices (User ID: usr_404)Active Sessions: 2

iPhone 15 Pro (Safari Mobile)LOGGED OUT

Device ID: dev_mobile_91a

Session: sess_mob_101

Session sess_mob_101 deleted. Token revoked.

MacBook Pro (Chrome Desktop)STILL ACTIVE

Device ID: dev_laptop_44b

Session: sess_lap_202

Unaffected! User remains logged in.

iPad Air (Native App)STILL ACTIVE

Device ID: dev_tablet_87c

Session: sess_tab_303

Unaffected! User remains logged in.

SERVER-SIDE STATE (Redis & PostgreSQL):

• DEL user:usr_404:session:sess_mob_101 ➔ OK

• user:usr_404:session:sess_lap_202 ➔ Active ✅

• user:usr_404:session:sess_tab_303 ➔ Active ✅

• user.token_version = 1 (Unchanged — other devices keep working!)

Single-Device Logout Mechanics

When a user clicks "Logout" on their phone, only the phone session is terminated. Because tokens are scoped with a unique session_id / device_id in the database or Redis session registry, the laptop and tablet sessions continue operating without interruption.

1. Client Request:

Mobile app sends POST /auth/logout with Refresh Token or session_id = "sess_mob_101".

2. Scoped Revocation:

Auth service deletes only sess_mob_101 from Redis/DB. Does NOT touch other session records.

3. Access Token Blacklisting:

Optional: Mobile access token jti is pushed to Redis blacklist with remaining 10m TTL.

4. Laptop & Tablet Status:

Laptop and tablet access tokens remain valid; their refresh tokens continue rotating cleanly.

---

1. The Core Dilemma: Stateless JWT vs Multi-Device Control

A purely stateless JWT is self-contained: any microservice holding the public key can verify its cryptographic signature and extract user claims (sub, roles, exp) with zero database calls.

Stateless JWT vs Multi-Device Control DilemmaInteractive Comparison

Click an approach below to simulate what happens when a user logs out of their Mobile Phone while also having an active session on their Laptop:

Simulation: Logout Triggered on Mobile Phone

📱 User's Mobile Phone (Initiator):Cleanly Logged Out ✅

💻 User's Laptop Session:STILL ACTIVE & UNINTERRUPTED ✅

🕵️ Attacker (Holding Stolen Token):Attacker on Mobile session BLOCKED ✅

Under-the-Hood Mechanism:

HDEL user:usr_404:sessions sess_mob_101; and mark session is_revoked in DB.

Verdict: Mobile is cleanly logged out. Laptop and Tablet remain 100% active and uninterrupted!

The Solution: Device-Scoped Hybrid Architecture

To achieve isolated device management without sacrificing API performance:

1. Short-Lived Access Tokens (5–15m): Include sub (User ID), device_id (or session_id), and ver (Token Version).
2. Stateful Refresh Tokens / KeyStores (7–30d): Stored per device in a Session Registry (Database + Redis cache).
3. Selective Invalidation: Single-device actions modify only that device's session record. Global actions bump the user's root token_version or set a Redis revoked_before watermark.

---

2. Multi-Device Architecture & Session Registry Patterns

Multi-Device Session Registry Architecture Patterns

PostgreSQL Schema (user_sessions)ACID DURABILITY

-- Schema: 1 User ➔ N Device Sessions
CREATE TABLE user_sessions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    device_id       VARCHAR(64) NOT NULL,        -- Hardware/Browser fingerprint
    device_name     VARCHAR(100),                -- "iPhone 15 Pro (Safari)"
    session_id      VARCHAR(64) NOT NULL UNIQUE, -- Instance ID
    family_id       UUID NOT NULL,               -- Token Family for RTR theft check
    token_hash      VARCHAR(64) NOT NULL UNIQUE, -- SHA-256(refresh_token)
    is_used         BOOLEAN DEFAULT FALSE,
    is_revoked      BOOLEAN DEFAULT FALSE,
    expires_at      TIMESTAMP WITH TIME ZONE NOT NULL,
    created_at      TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

-- Targeted Single-Device Logout:
UPDATE user_sessions SET is_revoked = TRUE 
WHERE user_id = :uid AND session_id = :currentSessionId;

PostgreSQL / MySQL user_sessions Table

Each login inserts a row in a relational user_sessions table linking user_id, device_id, session_id, and family_id.

Key Advantages:

✓ Full ACID compliance and transactional guarantees

✓ Rich audit log of active devices, login IPs, and session history

✓ Cascading foreign key deletes on user account deletion

Engineering Trade-offs:

⚠ Database I/O required on every token refresh request

⚠ Requires periodic cron vacuum/cleanup of expired session rows

Pattern A: Relational Session Registry (PostgreSQL / MySQL)

-- Refresh Token & Device Session Table
CREATE TABLE user_sessions (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    device_id       VARCHAR(64) NOT NULL,        -- Client hardware/browser fingerprint
    device_name     VARCHAR(100),                -- "iPhone 15 Pro", "MacBook Pro Chrome"
    session_id      VARCHAR(64) NOT NULL UNIQUE, -- Unique per login instance
    family_id       UUID NOT NULL,               -- Token Family for RTR theft detection
    token_hash      VARCHAR(64) NOT NULL UNIQUE, -- SHA-256 hash of refresh token
    parent_token_id UUID REFERENCES user_sessions(id),
    ip_address      VARCHAR(45),
    user_agent      TEXT,
    is_used         BOOLEAN DEFAULT FALSE,
    is_revoked      BOOLEAN DEFAULT FALSE,
    expires_at      TIMESTAMP WITH TIME ZONE NOT NULL,
    created_at      TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    last_active_at  TIMESTAMP WITH TIME ZONE DEFAULT NOW()
);

CREATE INDEX idx_user_sessions_lookup ON user_sessions(user_id, device_id);
CREATE INDEX idx_user_sessions_token_hash ON user_sessions(token_hash);
CREATE INDEX idx_user_sessions_family ON user_sessions(family_id);

Pattern B: Redis Hash Device Map (High-Throughput Caching)

In high-write environments, active sessions are stored in Redis Hashes for sub-millisecond lookups:

# Store active session for Device A
HSET user:usr_404:sessions sess_mob_101 '{"deviceId":"mob_1","familyId":"fam_A","tokenHash":"sha256...","issuedAt":1700000000}'
EXPIRE user:usr_404:sessions 2592000 # 30 days TTL

# Query all active devices for a user profile UI
HGETALL user:usr_404:sessions

# Invalidate single device (Mobile)
HDEL user:usr_404:sessions sess_mob_101

# Invalidate ALL devices (Logout Everywhere)
DEL user:usr_404:sessions

Pattern C: The KeyStore / Key-Token Pattern (Anonystick Model)

In this pattern, each device login generates a dedicated KeyStore record containing:

• publicKey & privateKey (or asymmetric key pair) specific to that device's session.
• refreshToken: The current active refresh token hash.
• refreshTokensUsed: An array tracking all historical rotated tokens in the current token family.

// KeyStore Structure per Device Login:
interface DeviceKeyStore {
  userId: string;
  deviceId: string;
  publicKey: string;
  refreshToken: string;
  refreshTokensUsed: string[];
  updatedAt: Date;
}

---

3. Deep-Dive: The 5 Invalidation Workflows

3.1 Scenario 1: Single-Device Logout (Isolated Device Invalidation)

When a user taps "Logout" on their mobile phone, only that device's session is terminated:

Single-Device Isolated Logout Execution FlowStep-by-Step Sequence

Step through the sequence below to see how logging out on Mobile Phone cleanly purges its session without affecting Laptop or Tablet:

STEP 1 OF 5

1. Mobile Client Submits Logout

Sends POST /auth/logout carrying refresh_token cookie and session_id = "sess_mob_101".

Payload / Database Execution:

POST /api/v1/auth/logout
Headers: { Authorization: "Bearer <jwt>", Cookie: "refresh_token=rt_mob_..." }
Body: { sessionId: "sess_mob_101", deviceId: "dev_mob_91a" }

Device Status: Mobile Phone = LOGGED OUT 🚪 | Laptop = ACTIVE ✅ | Tablet = ACTIVE ✅

Why Other Devices Are Unaffected:

1. The Laptop (sess_lap_202) and Tablet (sess_tab_303) records in user_sessions or Redis remain untouched.
2. The user's root token_version is not modified.
3. When the Laptop makes API calls, its Access Token is validated normally. When it calls /auth/refresh, its session record exists and rotates cleanly.

---

3.2 Scenario 2: Global Logout ("Sign Out of All Devices")

When a user clicks "Log out of all devices":

-- 1. Invalidate all refresh tokens in DB
UPDATE user_sessions 
SET is_revoked = TRUE 
WHERE user_id = :userId;

-- 2. Increment user token version
UPDATE users 
SET token_version = token_version + 1 
WHERE id = :userId;

# 3. Wipe all sessions in Redis
DEL user:usr_404:sessions

# 4. Set revocation timestamp to immediately invalidate all in-flight access tokens
SET user:usr_404:revoked_before 1700000000 EX 900

The Access Token Revocation Check:

Every API Gateway or Security Filter checks: $\text{if } (\text{jwt.iat} < \text{redis.get("user:revoked\_before:" + userId)}) \implies \text{HTTP 401 Unauthorized}$

---

3.3 Scenario 3: Password Update & Password Reset

Applications offer two distinct UX choices when a user updates their password:

Password Update Session Invalidation

Selective Session Invalidation — Device A Stays

Device A (sess_101) — Active

Device B (sess_202) — Revoked

Device C (sess_303) — Revoked

1

User on Device A

Submits current password + new password

2

Auth Service

Validates current password hash against DB

3

Auth Service

Updates password hash in users table

4

Auth Service

Selective Revocation — keep Device A session, revoke all others

KEY

5

Auth Service

Rotates fresh token pair for Device A

6

Device B / C

Next refresh attempt fails with 401 — session deleted

KEY

Option A Summary

Device A keeps its session active. All other sessions are selectively revoked via a targeted SQL update. Device A receives a fresh rotated token pair bound to the new credentials.

Click a step to inspect details

SQL Implementation:

-- Option A: Retain current device (sess_current), revoke all others
UPDATE user_sessions
SET is_revoked = TRUE
WHERE user_id = :userId
  AND session_id != :currentSessionId;

---

3.4 Scenario 4: Account Locked / Suspended (Admin / Anti-Fraud)

When an account is flagged for fraud, billing default, or security violation, access must be revoked immediately across all microservices:

Account Locked / Suspended Zero-Latency Containment EngineInteractive Simulator

Simulate how the API Gateway uses distributed Redis fast-path flags to instantly reject requests from all devices the millisecond an account is locked:

Target Account: usr_404STATUS: ACTIVE ✅

CURRENT SYSTEM STATE:

• PostgreSQL: users.status = 'ACTIVE'

• Redis Key: user:locked:usr_404 ➔ NULL

• Active JWTs: Valid

Test API Gateway Interception

Select an endpoint to fire an API request carrying a valid, signed JWT access token:

Click one of the endpoints above to test live request interception.

warning

The Redis lock check takes < 1 millisecond and intercepts requests at the API Gateway before any downstream microservice, database, or business logic executes.

---

3.5 Scenario 5: Token Theft & Automatic Compromise Containment

Under Refresh Token Rotation (RTR), refresh tokens can only be used once. If an attacker steals an already-rotated token ($RT_1$) and attempts to exchange it:

Refresh Token Rotation (RTR) Theft Detection & Family InvalidationTheft Simulation

Under Refresh Token Rotation (RTR), every token can be used exactly once. Step through the simulation below to see what happens when an attacker attempts to replay a stolen, already-rotated refresh token ($RT_1$):

STAGE 1 OF 4

1. Initial Login & Token Minting

User logs in. Auth server creates Token Family "fam_100" and issues Refresh Token RT-1.

Token Family Lineage (family_id: "fam_100")

RT-1 (Issued)

STATUS: ACTIVE

RT-2 (Not Yet Created)

STATUS: USED

Database / Security Execution:

INSERT INTO user_sessions (session_id, family_id, token_hash, is_used) VALUES ('sess_mob', 'fam_100', 'hash_RT1', FALSE);

---

4. Production Code Implementations

4.1 Node.js / Express KeyStore & Multi-Device Service

// auth.service.ts
import crypto from 'crypto';
import jwt from 'jsonwebtoken';
import { db } from './db';
import { redisClient } from './redis';

export class MultiDeviceAuthService {
  // 1. Login on a specific device
  static async login(userId: string, deviceId: string, deviceName: string) {
    const sessionId = `sess_${crypto.randomBytes(16).toString('hex')}`;
    const familyId = crypto.randomUUID();
    const rawRefreshToken = crypto.randomBytes(32).toString('hex');
    const tokenHash = crypto.createHash('sha256').update(rawRefreshToken).digest('hex');

    // Store session in PostgreSQL
    await db.query(
      `INSERT INTO user_sessions (user_id, device_id, device_name, session_id, family_id, token_hash, expires_at)
       VALUES ($1, $2, $3, $4, $5, $6, NOW() + INTERVAL '30 days')`,
      [userId, deviceId, deviceName, sessionId, familyId, tokenHash]
    );

    // Cache active session in Redis Hash
    await redisClient.hSet(`user:${userId}:sessions`, sessionId, JSON.stringify({
      deviceId,
      familyId,
      tokenHash,
      createdAt: Date.now()
    }));

    // Mint short-lived access token scoped to device & session
    const accessToken = jwt.sign(
      { sub: userId, deviceId, sessionId, ver: 1 },
      process.env.JWT_SECRET!,
      { expiresIn: '15m' }
    );

    return { accessToken, refreshToken: rawRefreshToken, sessionId };
  }

  // 2. Single-Device Logout (Isolated)
  static async logoutSingleDevice(userId: string, sessionId: string, accessTokenJti?: string) {
    // Revoke only this session in DB
    await db.query(
      `UPDATE user_sessions SET is_revoked = TRUE WHERE user_id = $1 AND session_id = $2`,
      [userId, sessionId]
    );

    // Remove from Redis device registry
    await redisClient.hDel(`user:${userId}:sessions`, sessionId);

    // Optional: Blacklist access token JTI for remaining 15 minutes
    if (accessTokenJti) {
      await redisClient.setEx(`blacklist:jti:${accessTokenJti}`, 900, 'logged_out');
    }

    return { success: true, message: 'Logged out of this device successfully' };
  }

  // 3. Global Logout ("Sign out of all devices")
  static async logoutAllDevices(userId: string) {
    // Revoke all sessions in DB
    await db.query(`UPDATE user_sessions SET is_revoked = TRUE WHERE user_id = $1`, [userId]);

    // Increment user token version
    await db.query(`UPDATE users SET token_version = token_version + 1 WHERE id = $1`, [userId]);

    // Wipe Redis session map
    await redisClient.del(`user:${userId}:sessions`);

    // Set revoked_before watermark to kill all in-flight access tokens
    const nowEpoch = Math.floor(Date.now() / 1000);
    await redisClient.setEx(`user:${userId}:revoked_before`, 900, String(nowEpoch));

    return { success: true, message: 'All devices logged out' };
  }
}

4.2 API Gateway Verification Middleware (Express / Fastify)

// auth.middleware.ts
import { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';
import { redisClient } from './redis';

export async function verifyJwtAndDeviceState(req: Request, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing Bearer token' });
  }

  const token = authHeader.substring(7);

  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET!) as {
      sub: string;
      deviceId: string;
      sessionId: string;
      iat: number;
      jti?: string;
    };

    const userId = payload.sub;

    // Fast-Check 1: Is Account Locked / Suspended?
    const isLocked = await redisClient.get(`user:${userId}:is_locked`);
    if (isLocked) {
      return res.status(403).json({ error: 'Account is locked. Contact support.' });
    }

    // Fast-Check 2: Was a Global Logout / Password Reset triggered after token iat?
    const revokedBefore = await redisClient.get(`user:${userId}:revoked_before`);
    if (revokedBefore && payload.iat < parseInt(revokedBefore, 10)) {
      return res.status(401).json({ error: 'Session expired due to security reset. Re-login required.' });
    }

    // Fast-Check 3: Is this specific Access Token JTI blacklisted?
    if (payload.jti) {
      const isBlacklisted = await redisClient.get(`blacklist:jti:${payload.jti}`);
      if (isBlacklisted) {
        return res.status(401).json({ error: 'Token has been logged out.' });
      }
    }

    req.user = payload;
    next();
  } catch (err) {
    return res.status(401).json({ error: 'Invalid or expired token' });
  }
}

---

5. Architectural Decision & Comparison Matrix

Mechanism	Scope	Latency	Redis Memory	Cross-Device Impact	Best For
device_id / session_id DB Deletion	Single Device	0 ms (at next refresh)	Zero	🟢 None (Other devices stay active)	Routine app logout
Redis jti Blacklist	Single Token	< 1 ms	Small (~50B per active logout)	🟢 None	High-security instant single-token revocation
Redis revoked_before Timestamp	Global User	< 1 ms	Minimal (1 key per user, 15m TTL)	🔴 All devices logged out	Password reset, "Logout all"
Redis user:locked Flag	Global User	< 1 ms	Minimal (1 key per user)	🔴 All requests blocked (403)	Anti-fraud freeze, Admin ban
RTR Token Family Invalidation	Token Family	< 1 ms	Zero	🔴 Specific device + stolen token revoked	Refresh token theft containment

---

6. Senior Engineering Interview Questions & Answers

Q1: If JWTs are stateless, how can you implement single-device logout without affecting the user's other logged-in devices?

Answer: You adopt a device-scoped hybrid model:

1. Assign a unique device_id and session_id during login and embed them into the Access Token claims.
2. Maintain individual session records (or KeyStores) in the database/Redis keyed by (user_id, session_id).
3. When the user logs out on Device A, delete only Device A's session record from Redis/DB and optionally blacklist Device A's jti.
4. Do not modify the user's root token_version. Device B and Device C's sessions remain valid and continue refreshing independently.

---

Q2: An admin locks a malicious user's account. How do you prevent their active 15-minute JWT access tokens from accessing microservices for the next 15 minutes?

Answer: Relying on database updates alone leaves a 15-minute vulnerability gap because stateless microservices do not query the DB on every request. To solve this with zero latency:

1. When locking the account, write a fast Redis key: SET user:locked:<userId> 1 EX 86400.
2. The API Gateway / Security Filter inspects EXISTS user:locked:<userId> in Redis on every incoming request.
3. If the key exists, the Gateway returns 403 Forbidden in < 1ms, terminating access across all microservices immediately.

---

Q3: What happens when a user changes their password and selects "Stay logged in on this device"?

Answer:

1. Update the password hash in the database.
2. Execute a scoped session cleanup: DELETE FROM user_sessions WHERE user_id = :uid AND session_id != :currentSessionId;.
3. Rotate and issue a fresh access + refresh token pair for :currentSessionId.
4. Other devices (bearing older session IDs) will fail on their next refresh attempt and be forced to re-authenticate with the new password.

---

🧠 Senior/Staff Interview Playbook: How to Ace Multi-Device JWT & Session Invalidation Interviews

1. The Senior Framing Strategy (First 60 Seconds)

When asked "How do you support 'Manage Devices', 'Sign Out Everywhere', and instant fraud lockouts if you use stateless JWTs?", frame the solution as a Two-Tier Hybrid State Machine:

1. Device-Scoped Stateful Control Plane (Refresh Tier): Every login creates an explicit row in user_sessions (and a Redis Hash entry HSET user:<id>:sessions <session_id>) containing device_id, session_id, family_id, and SHA-256(refresh_token).
2. Short-Lived Stateless Data Plane (Access Tier): Access Tokens ($5\text{–}15\text{ min}$ TTL) embed sub, session_id, and iat.
3. Granular vs. Global Eviction Primitives:
   • Single-Device Logout: Delete only session_id from the session registry + write blacklist:jti:<jti> (TTL = remaining access token seconds). Zero impact on the user's other devices.
   • Global Logout / Password Reset: Wipe the user's session registry + write a single Redis watermark SET user:<id>:revoked_before <now_epoch> EX 900. Any in-flight Access Token on any device with jwt.iat < revoked_before is immediately rejected at the API Gateway in $< 1\text{ ms}$.

---

2. Classic Interviewer Traps & Principal Rebuttals

Trap 1: "When our mobile app user is on a flaky 3G train connection and refreshes their token, the server rotates $RT_1 \to RT_2$, commits to the DB, and sends $RT_2$ back, but the TCP response drops. The mobile app retries with $RT_1$, and our Refresh Token Rotation (RTR) logic flags it as a hacker replay and nukes the user's session! How do you fix this in production?"

• Junior/Mid Answer: "Don't revoke the family on the first reuse, or increase the HTTP client timeout."
• Principal Rebuttal: "Network drops during /auth/refresh are a well-known production race condition in Refresh Token Rotation. If you strictly enforce zero-tolerance reuse on millisecond 0, flaky mobile networks cause massive false-positive session evictions. The Principal fix combines Grace-Window Idempotent Rotation or DPoP Sender-Constrained Refresh Tokens (RFC 9449):
  1. Grace Window ($5\text{–}10\text{ seconds}$) with Same-Context Fingerprint: When $RT_1$ is rotated to $RT_2$, record rotated_at and cache the encrypted response pair $(AT_2, RT_2)$ keyed by hash(RT_1) for 10 seconds. If a retry with $RT_1$ arrives within 10 seconds from the same device_id/TLS session and $RT_2$ has not yet been used, return the cached $(AT_2, RT_2)$ idempotently. If $RT_1$ is replayed after the grace window or after $RT_2$ has already been used on an API call, trigger immediate family_id revocation.
  2. DPoP Binding: If the refresh token is cryptographically bound to the mobile device's Secure Enclave private key (cnf.jkt), you don't even need destructive rotation because a stolen refresh token cannot be used without the hardware key."

Trap 2: "If a user opens 5 browser tabs in our React SPA and the Access Token expires at 12:00:00, all 5 tabs simultaneously call POST /auth/refresh with the same Refresh Token $RT_1$. Won't 4 of the 5 tabs trigger a false-positive Token Theft alarm?"

• Junior/Mid Answer: "Make the React app refresh earlier before the token expires."
• Principal Rebuttal: "Cross-tab concurrent refresh is one of the most common causes of production logout loops. You must solve it on both the Client and the Server:
  • Client-Side (Browser Web Locks API / BroadcastChannel): Use navigator.locks.request('auth_refresh_lock', async () => { ... }) so only one leader tab executes the network POST /auth/refresh call while the other 4 follower tabs await the lock and receive the new Access Token via BroadcastChannel.
  • Server-Side (Distributed Mutex + Idempotency Window): Acquire a short Redis lock SET lock:refresh:<family_id> 1 NX PX 3000 during token rotation so concurrent requests for the same family_id are serialized rather than racing on is_used."

Trap 3: "Should we store raw Refresh Tokens in the user_sessions PostgreSQL table so we can look them up on /auth/refresh?"

• Junior/Mid Answer: "Yes, put a unique B-Tree index on the refresh_token column."
• Principal Rebuttal: "Never store raw Refresh Tokens in the database! A Refresh Token is a long-lived bearer credential equivalent to a password for 30 days. If an attacker achieves read-only SQL injection or steals a database snapshot, raw refresh tokens allow immediate account takeover of every active user. Always generate a 256-bit cryptographically random token, send the raw value to the client once, and store only SHA-256(raw_refresh_token) in PostgreSQL and Redis."

---

3. Mid-Level vs. Principal Candidate Cheat Sheet

Concept / Scenario	Mid-Level Candidate Says	Principal Candidate Demonstrates
Single-Device vs. Global Logout	"Bump the user's token_version in the users table on logout."	"Bumping users.token_version logs out all devices. For single-device logout, delete only (user_id, session_id) in Redis/DB; reserve token_version / revoked_before for global eviction."
Database Storage of Refresh Tokens	"Store the refresh token UUID in the database."	"Generate 32 bytes of SecureRandom entropy and store only the hex-encoded SHA-256 digest (token_hash) so DB read leaks cannot hijack sessions."
Concurrent Multi-Tab Refresh	"Each tab refreshes when it gets a 401."	"Coordinate tabs using the browser Web Locks API (navigator.locks) + BroadcastChannel, backed by a server-side 10-second idempotent rotation grace window."
Zero-Latency Account Ban	"Set users.is_locked = true in PostgreSQL."	"Write SET user:<id>:is_locked 1 in Redis and enforce a <1ms check at the API Gateway (or local gateway memory cache synced via Redis Client-Side Caching / PubSub) to block in-flight 15m JWTs."

Related References & Guides

• JWT, OAuth 2.1 & OpenID Connect (OIDC) — Principal Architecture Deep Dive — JOSE (JWS/JWE/JWKS), PKCE S256 math, Phantom Token pattern, and DPoP (RFC 9449).
• Cookies vs Sessions vs JWT — Fundamental tradeoffs between cookie session state and stateless JWTs.
• Authentication & Authorization — OAuth 2.0, OpenID Connect, and Spring Security.
• PostgreSQL Heap Storage & Internals — How PostgreSQL stores and indexes session and token tables.