kienbui1995/authentication-patterns

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