Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes. Use when implementing auth, reviewing auth flows, or choosing auth providers.
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
[P0-MUST] Set short expiry on access tokens (15 minutes or less).
[P0-MUST] Store tokens in httpOnly, Secure, SameSite=Lax cookies — never in localStorage or sessionStorage.
[P0-MUST] Implement refresh token rotation — each refresh token is single-use.
[P0-MUST] Maintain a server-side blocklist for revoked refresh tokens.
[P1-SHOULD] Include only essential claims in JWT payload (sub, iat, exp, role). Keep it small.
[P1-SHOULD] Use asymmetric signing (RS256 or ES256) for distributed systems; symmetric (HS256) for single-service only.
[P1-SHOULD] Validate iss, aud, and exp claims on every request.
[P2-MAY] Use JWE (encrypted JWT) when token payload contains sensitive data.
Token Storage Comparison
Storage
XSS Safe
CSRF Safe
Recommendation
httpOnly cookie
Yes
No (needs CSRF token)
Recommended
localStorage
No
Yes
Never use for auth tokens
sessionStorage
No
Yes
Never use for auth tokens
In-memory (JS variable)
Yes
Yes
OK for SPAs, lost on refresh
PROVIDER_PATTERNS
Comparison
Provider
Type
Best For
Pricing
Key Features
NextAuth / Auth.js
OSS library
Next.js apps wanting full control
Free
80+ providers, DB adapters, self-hosted
Clerk
Managed service
Fast launch, pre-built UI, user management
Free tier, then per-MAU
Drop-in components, user dashboard, org support
Supabase Auth
Managed (part of Supabase)
Apps already using Supabase for DB/storage
Free tier, then per-MAU
Row-level security integration, magic links, SSO
Lucia
OSS library
Full control, minimal abstraction
Free
Session-based, framework-agnostic, type-safe
When to Use Each
NextAuth / Auth.js: You want provider flexibility, self-hosting, and database session control. Best when you need custom flows.
Clerk: You want auth done fast with pre-built UI components. Best for MVPs and teams that don't want to build auth UI.
Supabase Auth: You're already using Supabase. Auth integrates with RLS policies for row-level security.
Lucia: You want a minimal, type-safe session library without framework lock-in.
Rate limiting: Login endpoint limited to 5-10 attempts per minute per IP.
CSRF protection: Anti-CSRF tokens on all state-changing requests (or use SameSite=Lax cookies).
Password hashing: Using bcrypt (cost 12+) or argon2id — never MD5, SHA-1, or plain SHA-256.
HTTPS only: All auth endpoints served over TLS. Cookies have Secure flag.
Input validation: Email format, password length (min 8, max 128), no SQL/NoSQL injection vectors.
Account enumeration: Login and registration return the same response whether account exists or not.
Session invalidation: Logout invalidates server-side session/refresh token, not just client cookie.
MFA support: TOTP (authenticator app) or WebAuthn as second factor for sensitive accounts.
Password reset: Time-limited tokens (1 hour), single-use, sent over secure channel.
Audit logging: Log auth events (login, logout, failed attempts, password changes) with timestamp and IP.
Password Hashing
// Using bcrypt
import bcrypt from "bcrypt";
const SALT_ROUNDS = 12;
async function hashPassword(password: string): Promise<string> {
return bcrypt.hash(password, SALT_ROUNDS);
}
async function verifyPassword(password: string, hash: string): Promise<boolean> {
return bcrypt.compare(password, hash);
}
// Using argon2 (preferred for new projects)
import argon2 from "argon2";
async function hashPassword(password: string): Promise<string> {
return argon2.hash(password, { type: argon2.argon2id });
}
async function verifyPassword(hash: string, password: string): Promise<boolean> {
return argon2.verify(hash, password);
}
COMMON_MISTAKES
Mistake
Risk
Fix
Storing JWT in localStorage
XSS can steal tokens
Use httpOnly cookies
Long-lived JWTs (days/weeks)
Stolen token is valid for extended period
15 min access token + refresh rotation
Missing CSRF protection
Attackers can forge requests from other sites
SameSite=Lax cookies + CSRF token
Weak password requirements
Brute force and credential stuffing
Min 8 chars, check against breached password lists
Exposing user existence on login
Account enumeration
Generic "Invalid credentials" message
Not rotating refresh tokens
Stolen refresh token grants indefinite access
Single-use refresh tokens with rotation
Hardcoding secrets in source
Credential leak via git history
Use environment variables, never commit secrets
Missing rate limiting on login
Brute force attacks
5-10 attempts/min per IP, exponential backoff
Rolling your own crypto
Subtle vulnerabilities
Use established libraries (bcrypt, argon2, jose)
Not validating JWT claims
Token misuse across services
Always verify iss, aud, exp
1---2name: authentication-patterns3description: Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes. Use when implementing auth, reviewing auth flows, or choosing auth providers.4---56# Authentication Patterns Skill78Reference for implementing secure, production-ready authentication.910## WHEN_TO_USE1112Apply 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.1314## AUTH_APPROACHES1516| Approach | How It Works | Best For | Drawbacks |17|----------|-------------|----------|-----------|18| 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 |19| 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 |20| 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 |21| Passkeys / WebAuthn | Cryptographic key pair, no passwords | High-security apps, passwordless UX | Limited browser support legacy, user education needed |2223### Decision Guide2425- **Server-rendered app with simple needs** → Session-based26- **SPA or mobile app calling APIs** → JWT with refresh token rotation27- **Want social login or SSO** → OAuth 2.0 / OIDC28- **Greenfield with modern UX goals** → Passkeys + OAuth fallback2930## JWT_BEST_PRACTICES3132### Token Lifecycle3334```35Login → Access Token (short-lived) + Refresh Token (long-lived, rotated)36 │37 ├─ Access Token: 15 min expiry, sent via httpOnly cookie or Authorization header38 │39 └─ Refresh Token: 7-30 day expiry, stored in httpOnly secure cookie40 │41 └─ On use: issue new access + new refresh token, invalidate old refresh token42```4344### Rules4546- [P0-MUST] Set short expiry on access tokens (15 minutes or less).47- [P0-MUST] Store tokens in `httpOnly`, `Secure`, `SameSite=Lax` cookies — never in `localStorage` or `sessionStorage`.48- [P0-MUST] Implement refresh token rotation — each refresh token is single-use.49- [P0-MUST] Maintain a server-side blocklist for revoked refresh tokens.50- [P1-SHOULD] Include only essential claims in JWT payload (sub, iat, exp, role). Keep it small.51- [P1-SHOULD] Use asymmetric signing (RS256 or ES256) for distributed systems; symmetric (HS256) for single-service only.52- [P1-SHOULD] Validate `iss`, `aud`, and `exp` claims on every request.53- [P2-MAY] Use JWE (encrypted JWT) when token payload contains sensitive data.5455### Token Storage Comparison5657| Storage | XSS Safe | CSRF Safe | Recommendation |58|---------|----------|-----------|----------------|59| `httpOnly` cookie | Yes | No (needs CSRF token) | Recommended |60| `localStorage` | No | Yes | Never use for auth tokens |61| `sessionStorage` | No | Yes | Never use for auth tokens |62| In-memory (JS variable) | Yes | Yes | OK for SPAs, lost on refresh |6364## PROVIDER_PATTERNS6566### Comparison6768| Provider | Type | Best For | Pricing | Key Features |69|----------|------|----------|---------|-------------|70| NextAuth / Auth.js | OSS library | Next.js apps wanting full control | Free | 80+ providers, DB adapters, self-hosted |71| Clerk | Managed service | Fast launch, pre-built UI, user management | Free tier, then per-MAU | Drop-in components, user dashboard, org support |72| Supabase Auth | Managed (part of Supabase) | Apps already using Supabase for DB/storage | Free tier, then per-MAU | Row-level security integration, magic links, SSO |73| Lucia | OSS library | Full control, minimal abstraction | Free | Session-based, framework-agnostic, type-safe |7475### When to Use Each7677- **NextAuth / Auth.js**: You want provider flexibility, self-hosting, and database session control. Best when you need custom flows.78- **Clerk**: You want auth done fast with pre-built UI components. Best for MVPs and teams that don't want to build auth UI.79- **Supabase Auth**: You're already using Supabase. Auth integrates with RLS policies for row-level security.80- **Lucia**: You want a minimal, type-safe session library without framework lock-in.8182### NextAuth.js Setup Pattern8384```typescript85// app/api/auth/[...nextauth]/route.ts86import NextAuth from "next-auth";87import GitHub from "next-auth/providers/github";88import { PrismaAdapter } from "@auth/prisma-adapter";89import { prisma } from "@/lib/prisma";9091export const { handlers, auth, signIn, signOut } = NextAuth({92 adapter: PrismaAdapter(prisma),93 providers: [94 GitHub({95 clientId: process.env.GITHUB_CLIENT_ID!,96 clientSecret: process.env.GITHUB_CLIENT_SECRET!,97 }),98 ],99 callbacks: {100 session({ session, user }) {101 session.user.id = user.id;102 return session;103 },104 },105});106```107108## SECURITY_CHECKLIST109110### Before Shipping Auth111112- [ ] **Rate limiting**: Login endpoint limited to 5-10 attempts per minute per IP.113- [ ] **CSRF protection**: Anti-CSRF tokens on all state-changing requests (or use `SameSite=Lax` cookies).114- [ ] **Password hashing**: Using bcrypt (cost 12+) or argon2id — never MD5, SHA-1, or plain SHA-256.115- [ ] **HTTPS only**: All auth endpoints served over TLS. Cookies have `Secure` flag.116- [ ] **Input validation**: Email format, password length (min 8, max 128), no SQL/NoSQL injection vectors.117- [ ] **Account enumeration**: Login and registration return the same response whether account exists or not.118- [ ] **Session invalidation**: Logout invalidates server-side session/refresh token, not just client cookie.119- [ ] **MFA support**: TOTP (authenticator app) or WebAuthn as second factor for sensitive accounts.120- [ ] **Password reset**: Time-limited tokens (1 hour), single-use, sent over secure channel.121- [ ] **Audit logging**: Log auth events (login, logout, failed attempts, password changes) with timestamp and IP.122123### Password Hashing124125```typescript126// Using bcrypt127import bcrypt from "bcrypt";128129const SALT_ROUNDS = 12;130131async function hashPassword(password: string): Promise<string> {132 return bcrypt.hash(password, SALT_ROUNDS);133}134135async function verifyPassword(password: string, hash: string): Promise<boolean> {136 return bcrypt.compare(password, hash);137}138```139140```typescript141// Using argon2 (preferred for new projects)142import argon2 from "argon2";143144async function hashPassword(password: string): Promise<string> {145 return argon2.hash(password, { type: argon2.argon2id });146}147148async function verifyPassword(hash: string, password: string): Promise<boolean> {149 return argon2.verify(hash, password);150}151```152153## COMMON_MISTAKES154155| Mistake | Risk | Fix |156|---------|------|-----|157| Storing JWT in `localStorage` | XSS can steal tokens | Use `httpOnly` cookies |158| Long-lived JWTs (days/weeks) | Stolen token is valid for extended period | 15 min access token + refresh rotation |159| Missing CSRF protection | Attackers can forge requests from other sites | `SameSite=Lax` cookies + CSRF token |160| Weak password requirements | Brute force and credential stuffing | Min 8 chars, check against breached password lists |161| Exposing user existence on login | Account enumeration | Generic "Invalid credentials" message |162| Not rotating refresh tokens | Stolen refresh token grants indefinite access | Single-use refresh tokens with rotation |163| Hardcoding secrets in source | Credential leak via git history | Use environment variables, never commit secrets |164| Missing rate limiting on login | Brute force attacks | 5-10 attempts/min per IP, exponential backoff |165| Rolling your own crypto | Subtle vulnerabilities | Use established libraries (bcrypt, argon2, jose) |166| Not validating JWT claims | Token misuse across services | Always verify `iss`, `aud`, `exp` |
Run npx skillmds@latest add jantoniofc/authentication-patterns in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes. Use when implementing auth, reviewing auth flows, or choosing auth providers. It is listed under Security on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: CAUTION, Skill Scanner: PASS. Capability flags: reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
JantonioFC (@jantoniofc) published this skill. Their other Agent Skills are listed on their SkillMD profile.