kienbui1995 Authentication Patterns
Overview
Auth is the most security-critical part of any application. Use proven patterns, never roll your own crypto.
When to Use
- Implementing login/signup flows
- Adding OAuth/social login
- Designing API authentication
- Reviewing auth security
- Implementing role-based access control
Pattern Selection
| Pattern | Best For | Avoid When |
|---|---|---|
| Session + cookie | Server-rendered web apps | Mobile/SPA without same-origin |
| JWT (access + refresh) | SPAs, mobile apps, microservices | Simple server-rendered apps |
| OAuth 2.0 + OIDC | Social login, SSO, third-party auth | Internal-only tools |
| API keys | Server-to-server, public APIs | User-facing auth |
JWT Best Practices
- Short-lived access tokens — 15 minutes max
- Long-lived refresh tokens — stored in httpOnly cookie, rotated on use
- Never store JWTs in localStorage — XSS vulnerable
- Include minimal claims — user ID, roles. Not PII.
- Validate on every request — check signature, expiry, issuer
- Use RS256 or ES256 — not HS256 for distributed systems
OAuth 2.0 Flow (Authorization Code + PKCE)
1. Client generates code_verifier + code_challenge
2. Redirect to /authorize?response_type=code&code_challenge=...
3. User authenticates with provider
4. Provider redirects back with authorization code
5. Client exchanges code + code_verifier for tokens
6. Store access token in memory, refresh token in httpOnly cookie
Security Checklist
- Passwords hashed with bcrypt/argon2 (cost factor ≥12)
- Rate limiting on login endpoints
- Account lockout after N failed attempts
- CSRF protection on session-based auth
- Refresh token rotation (one-time use)
- Secure cookie flags:
httpOnly,secure,sameSite=strict - No secrets in JWTs or URLs
Integration
- magic-powers:api-design — auth headers and error responses
- magic-powers:security-review — audit auth implementation