Authentication & Authorization
Choosing the right authentication strategy and understanding session vs token-based approaches for secure applications.
Quick Navigation: JWT • Session • OAuth • Token Storage • Comparison
Authentication vs Authorization
- Authentication: "Who are you?" - Verifying identity
- Authorization: "What can you do?" - Verifying permissions
JWT (JSON Web Tokens)
Self-contained tokens that carry user information, signed to prevent tampering.
How JWT Works
Advantages
- ✓Stateless: No server-side storage needed
- ✓Scalable: Works with any server instance
- ✓Cross-domain: Works across different domains
- ✓Mobile-friendly: Easy to use in native apps
Disadvantages
- ✗Can't be revoked: Valid until expiry
- ✗Token size: Larger than session IDs
- ✗Payload readable: Don't store sensitive data
- ✗XSS vulnerable: If stored in localStorage
🎯 Best For:
Microservices, APIs, mobile apps, cross-domain authentication, serverless architectures.
Session-Based Authentication
Server stores session data, client only holds session ID in cookie.
How Sessions Work
Advantages
- ✓Revocable: Can invalidate sessions instantly
- ✓XSS-safe: HttpOnly cookies not accessible via JS
- ✓Small payload: Only session ID sent
- ✓Full control: Server manages session data
Disadvantages
- ✗Stateful: Requires session storage
- ✗Scaling: Need shared session store
- ✗Same-origin: Cookies are domain-restricted
- ✗CSRF vulnerable: Requires CSRF protection
🎯 Best For:
Traditional web apps, when you need instant session invalidation, banking/financial apps.
OAuth 2.0 Flows
Authorization Code Flow (with PKCE)
Most secure flow for web and mobile apps.
Implicit Flow (Deprecated)
Was used for SPAs, now replaced by Auth Code + PKCE.
⚠️ Avoid: Token exposed in URL, no refresh tokens
Client Credentials Flow
For server-to-server communication, no user involved.
🎯 Best For: Backend services, APIs, microservices
Token Storage Trade-offs
LocalStorage
Pros
- ✓ Easy to implement
- ✓ Works across tabs
- ✓ No CSRF vulnerability
Cons
- ✗ XSS vulnerable (JS accessible)
- ✗ Never use for sensitive apps
HttpOnly Cookies
Pros
- ✓ Not accessible via JavaScript (XSS-safe)
- ✓ Auto-sent with requests
- ✓ Can be Secure and SameSite
Cons
- ✗ Requires CSRF protection
- ✗ Same-origin restrictions
- ✗ Size limited (~4KB)
✅ Recommended: Use HttpOnly cookies for access tokens
Memory (In-App State)
Pros
- ✓ Most secure (not persisted)
- ✓ XSS can't access easily
Cons
- ✗ Lost on page refresh
- ✗ Requires silent refresh mechanism
Comparison Table
| Aspect | JWT | Session |
|---|---|---|
| State | Stateless | Stateful |
| Scalability | Easy | Requires shared store |
| Revocation | Hard | Instant |
| Cross-domain | Yes | No |
| XSS Risk | High (if localStorage) | Low (HttpOnly cookie) |
| CSRF Risk | Low | High (needs protection) |
Best Practices
- 1.Use short-lived access tokens with refresh token rotation.
- 2.Store tokens in HttpOnly cookies when possible.
- 3.Implement CSRF protection for cookie-based auth.
- 4.Use PKCE for OAuth in SPAs and mobile apps.
- 5.Implement token blacklisting for JWT if revocation needed.