Authentication Patterns for Web Applications

"Who are you?" (Authentication) and "What can you do?" (Authorization) are the pillars of web security. Choosing the wrong pattern can leave your users vulnerable to XSS or CSRF attacks.

1. Session Cookies (The Classic)

• How it works: The user logs in. The server creates a unique session_id, stores it in a fast database (Redis), and sends it to the browser as a HttpOnly cookie.
• Pros: Most Secure. JavaScript cannot read an HttpOnly cookie, making it immune to XSS token theft. Easy to revoke (just delete the key from Redis).
• Cons: Requires server state. The server must look up the session on every single request, which adds latency.

2. JSON Web Tokens (The Stateless Modern)

• How it works: The server signs a JSON object (JWT) and sends it to the client. The client stores it (often in LocalStorage) and sends it in the Authorization: Bearer <token> header.
• Pros: Stateless. The server just verifies the cryptographic signature (CPU cheap) without needing a database lookup (IO expensive). Great for microservices.
• Cons: Security Risk. If stored in LocalStorage, it is vulnerable to XSS. Hard to revoke—if a token is stolen, it remains valid until it expires (unless you implement complex blacklisting).

3. OAuth (Social Login)

• How it works: "Login with Google." You delegate the authentication to a trusted third party.
• Pros: Better UX (no new password to remember).
• Cons: You rely on the provider. If Google is down, nobody can log in to your app.

Best Practice: For traditional web apps, Session Cookies are still the golden standard for security. For Mobile Apps and Microservice APIs, use JWTs (but keep life-spans short, e.g., 15 minutes).