Authentication Patterns Skill

Reference for implementing secure, production-ready authentication.

WHEN_TO_USE

Apply this skill when implementing authentication in a project, reviewing existing auth flows for security issues, choosing between auth providers, or migrating between auth strategies. Use the security checklist before shipping any auth-related change.

AUTH_APPROACHES

Approach	How It Works	Best For	Drawbacks
Session-based	Server stores session in DB/Redis, client holds session ID cookie	Traditional server-rendered apps, apps needing instant revocation	Requires server-side storage, harder to scale horizontally without shared store
JWT (stateless)	Server signs token, client sends it on each request	API-first apps, microservices, mobile clients	Cannot revoke without blocklist, token size grows with claims
OAuth 2.0 / OIDC	Delegates auth to external provider (Google, GitHub, etc.)	Social login, enterprise SSO, reducing auth responsibility	More complex flow, depends on external provider availability
Passkeys / WebAuthn	Cryptographic key pair, no passwords	High-security apps, passwordless UX	Limited browser support legacy, user education needed

Decision Guide

• Server-rendered app with simple needs → Session-based
• SPA or mobile app calling APIs → JWT with refresh token rotation
• Want social login or SSO → OAuth 2.0 / OIDC
• Greenfield with modern UX goals → Passkeys + OAuth fallback

JWT_BEST_PRACTICES

Token Lifecycle

Login → Access Token (short-lived) + Refresh Token (long-lived, rotated)
  │
  ├─ Access Token: 15 min expiry, sent via httpOnly cookie or Authorization header
  │
  └─ Refresh Token: 7-30 day expiry, stored in httpOnly secure cookie
       │
       └─ On use: issue new access + new refresh token, invalidate old refresh token

Rules