Auth Patterns — Authentication & Authorization

SECURITY-CRITICAL SKILL — Auth is the front door. Get it wrong and nothing else matters.

Authentication Methods

| Method | How It Works | Best For | |--------|-------------|----------| | JWT | Signed token sent with each request | SPAs, microservices, mobile APIs | | Session-based | Server stores session, client holds cookie | Traditional web apps, SSR | | OAuth 2.0 | Delegated auth via authorization server | "Login with Google/GitHub", API access | | API Keys | Static key sent in header | Internal services, public APIs | | Magic Links | One-time login link via email | Low-friction onboarding, B2C | | Passkeys/WebAuthn | Hardware/biometric challenge-response | High-security apps, passwordless |

JWT Patterns

Dual-Token Strategy

Short-lived access token + long-lived refresh token:

Client → POST /auth/login → Server
Client ← { access_token, refresh_token }

Client → GET /api/data (Authorization: Bearer <access>) → Server
Client ← 401 Expired

Client → POST /auth/refresh { refresh_token } → Server
Client ← { new_access_token, rotated_refresh_token }

Token Structure

{
  "header": { "alg": "RS256", "typ": "JWT", "kid": "key-2024-01" },
  "payload": {
    "sub": "user_abc123",
    "iss": "https://auth.example.com",
    "aud": "https://api.example.com",
    "exp": 1700000900,
    "iat": 1700000000,
    "jti": "unique-token-id",
    "roles": ["user"],
    "scope": "read:profile write:profile"
  }
}

Signing Algorithms

| Algorithm | Type | When to Use | |-----------|------|-------------| | RS256 | Asymmetric (RSA) | Microservices — only auth server holds private key | | ES256 | Asymmetric (ECDSA) | Same as RS256, smaller keys and signatures | | HS256 | Symmetric | Single-server apps — all verifiers share secret |

Prefer RS256/ES256 in distributed systems.

Token Storage

| Storage | XSS Safe | CSRF Safe | Recommendation | |---------|----------|-----------|----------------| | httpOnly cookie | Yes | No (add CSRF token) | Best for web apps | | localStorage | No | Yes | Avoid — XSS exposes tokens | | In-memory | Yes | Yes | Good for SPAs, lost on refresh |

Set-Cookie: access_token=eyJ...; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=900

Expiration Strategy

| Token | Lifetime | Rotation | |-------|----------|----------| | Access token | 5–15 minutes | Issued on refresh | | Refresh token | 7–30 days | Rotate on every use | | ID token | Match access token | Not refreshed |

OAuth 2.0 Flows

| Flow | Client Type | When to Use | |------|-------------|-------------| | Authorization Code + PKCE | Public (SPA, mobile) | Default for all public clients | | Authorization Code | Confidential (server) | Server-rendered web apps with backend | | Client Credentials | Machine-to-machine | Service-to-service, cron jobs | | Device Code | Input-constrained | Smart TVs, IoT, CLI on headless servers |

Implicit flow is deprecated. Always use Authorization Code + PKCE for public clients.

PKCE Flow

1. Client generates code_verifier (random 43-128 chars)
2. Client computes code_challenge = BASE64URL(SHA256(code_verifier))
3. Redirect to /authorize?code_challenge=...&code_challenge_method=S256
4. User authenticates, server redirects back with authorization code
5. Client exchanges code + code_verifier for tokens at /token
6. Server verifies SHA256(code_verifier) == code_challenge

Session Management

Server-Side Sessions

Client Cookie:  session_id=a1b2c3d4 (opaque, random, no user data)
Server Store:   { "a1b2c3d4": { userId: 123, roles: ["admin"], expiresAt: ... } }

| Store | Speed | When to Use | |-------|-------|-------------| | Redis | Fast | Production default — TTL support, horizontal scaling | | PostgreSQL | Moderate | When Redis is overkill, need audit trail | | In-memory | Fastest | Development only |

Session Security

| Threat | Prevention | |--------|------------| | Session fixation | Regenerate session ID after login | | Session hijacking | httpOnly + Secure cookies, bind to IP/user-agent | | CSRF | SameSite cookies + CSRF tokens | | Idle timeout | Expire after 15–30 min inactivity | | Absolute timeout | Force re-auth after 8–24 hours |

Authorization Patterns

| Pattern | Granularity | When to Use | |---------|-------------|-------------| | RBAC | Coarse (admin, editor, viewer) | Most apps — simple role hierarchy | | ABAC | Fine (attributes: dept, time, location) | Enterprise — context-dependent access | | Permission-based | Medium (post:create, user:delete) | APIs — decouple permissions from roles | | Policy-based (OPA/Cedar) | Fine | Microservices — externalized, auditable rules | | ReBAC | Fine (owner, member, shared-with) | Social apps, Google Drive-style sharing |

RBAC Implementation

const ROLE_PERMISSIONS: Record<string, string[]> = {
  admin:  ["user:read", "user:write", "user:delete", "post:read", "post:write", "post:delete"],
  editor: ["user:read", "post:read", "post:write"],
  viewer: ["user:read", "post:read"],
};

function requirePermission(permission: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const permissions = ROLE_PERMISSIONS[req.user.role] ?? [];
    if (!permissions.includes(permission)) {
      return res.status(403).json({ error: "Forbidden" });
    }
    next();
  };
}

app.delete("/api/users/:id", requirePermission("user:delete"), deleteUser);

Password Security

| Algorithm | Recommended | Memory-Hard | Notes | |-----------|------------|-------------|-------| | Argon2id | First choice | Yes | Resists GPU/ASIC attacks | | bcrypt | Yes | No | Battle-tested, 72-byte limit | | scrypt | Yes | Yes | Good alternative | | PBKDF2 | Acceptable | No | NIST approved, weaker vs GPU | | SHA-256/MD5 | Never | No | Not password hashing |

NIST 800-63B: Favor length (12+ chars) over complexity rules. Check against breached password lists. Don't force periodic rotation unless breach suspected.

Multi-Factor Authentication

| Factor | Security | Notes | |--------|----------|-------| | TOTP (Authenticator app) | High | Offline-capable, Google Authenticator / Authy | | WebAuthn/Passkeys | Highest | Phishing-resistant, hardware-backed | | SMS OTP | Medium | Vulnerable to SIM swap — avoid for high-security | | Hardware keys (FIDO2) | Highest | YubiKey — best for admin accounts | | Backup codes | Low (fallback) | One-time use, generate 10, store hashed |

Security Headers

| Header | Value | |--------|-------| | Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | | Content-Security-Policy | Restrict script sources, no inline scripts | | X-Content-Type-Options | nosniff | | X-Frame-Options | DENY | | Referrer-Policy | strict-origin-when-cross-origin | | CORS | Whitelist specific origins, never * with credentials |

Common Vulnerabilities

| # | Vulnerability | Prevention | |---|--------------|------------| | 1 | Broken authentication | MFA, strong password policy, breach detection | | 2 | Session fixation | Regenerate session ID on login | | 3 | JWT alg:none attack | Reject none, validate alg against allowlist | | 4 | JWT secret brute force | Use RS256/ES256, strong secrets (256+ bits) | | 5 | CSRF | SameSite cookies, CSRF tokens | | 6 | Credential stuffing | Rate limiting, breached password check, MFA | | 7 | Insecure password storage | Argon2id/bcrypt, never encrypt (hash instead) | | 8 | Insecure password reset | Signed time-limited tokens, invalidate after use | | 9 | Open redirect | Validate redirect URIs against allowlist | | 10 | Token leakage in URL | Send tokens in headers or httpOnly cookies only | | 11 | Privilege escalation | Server-side role checks on every request | | 12 | OAuth redirect_uri mismatch | Exact match redirect URI validation, no wildcards | | 13 | Timing attacks | Constant-time comparison for secrets |

NEVER Do

| # | Rule | Why | |---|------|-----| | 1 | NEVER store passwords in plaintext or reversible encryption | One breach exposes every user | | 2 | NEVER put tokens in URLs or query parameters | Logged by servers, proxies, referrer headers | | 3 | NEVER use alg: none or allow algorithm switching in JWTs | Attacker forges tokens | | 4 | NEVER trust client-side role/permission claims | Users can modify any client-side value | | 5 | NEVER use MD5, SHA-1, or plain SHA-256 for password hashing | No salt, no work factor — cracked in seconds | | 6 | NEVER skip HTTPS in production | Tokens and credentials sent in cleartext | | 7 | NEVER log tokens, passwords, or secrets | Logs are broadly accessible and retained | | 8 | NEVER use long-lived tokens without rotation | A single leak grants indefinite access | | 9 | NEVER implement your own crypto | Use established libraries — jose, bcrypt, passport | | 10 | NEVER return different errors for "user not found" vs "wrong password" | Enables user enumeration |