Authentication verifies who a user is. Session management maintains that verification across multiple requests. Weaknesses in either area are among the most commonly exploited vulnerabilities.
└─ Server treats attacker as the authenticated user
└─ Prevention: HttpOnly cookies (block XSS theft), HTTPS (block sniffing),
IP binding (alert on IP change), session rotation
Concurrent Session Control
# Limit concurrent sessions per user
# When user logs in, check active session count
# If > N active sessions, invalidate oldest or prompt:
# "You are logged in from another device. Log out other device?"
OAuth 2.0 & OpenID Connect
sequenceDiagram
User->>App: Click "Login with Google"
App->>Auth Server: Redirect to /authorize
Auth Server->>User: "App wants access to your email"
User->>Auth Server: Approve
Auth Server->>App: Authorization code
App->>Auth Server: Exchange code for tokens (with client_secret)
Auth Server->>App: Access token + ID token (JWT)
App->>Resource Server: API call with access token
Resource Server->>App: User data
OAuth 2.0 Grant Types
Grant Type
Use Case
Security
Authorization Code
Server-side web apps
Best — tokens never see browser
PKCE (Proof Key for Code Exchange)
Mobile apps, SPAs
Best for public clients
Client Credentials
Server-to-server
No user involved
Implicit (DEPRECATED)
Legacy SPAs
Token in URL — insecure
Resource Owner Password
Legacy apps (DEPRECATED)
App sees password — avoid
Real Case: Authentication Failure at Yahoo (2014)
└─ Attacker compromised Yahoo's user database
└─ 500 million accounts stolen (names, email, phone numbers)
└─ Passwords stored with MD5 (should have been bcrypt/Argon2)
└─ 3 billion accounts eventually disclosed (2013+2014 combined)
└─ Yahoo's sale to Verizon reduced by $350M due to breach
└─ Verizon required Yahoo to share 50% of legal costs
Authentication lessons:
1. MD5 is NOT password hashing — it is fast hash for checksums
2. Even with MD5, all passwords were unsalted — rainbow table in minutes
3. Security questions (backup auth) were also compromised
4. No MFA available at the time — all-or-nothing on password
Key Takeaways
Passwords are the weakest authentication factor — always layer with MFA for any external-facing application
Password storage must use adaptive hashing algorithms (Argon2id, bcrypt, PBKDF2) — never MD5, SHA-1, or unsalted hashes
Session IDs must be: long (128+ bits), cryptographically random, HTTPOnly+Secure+SameSite, regenerated on login, and bound to user context
Session fixation attack: attacker gives victim a session ID → victim logs in → attacker hijacks — prevented by regenerating session ID on authentication
The Yahoo 2014 breach (3B accounts) used MD5 for password storage — a modern GPU cracks 100B+ MD5 hashes/second
OAuth 2.0 Authorization Code + PKCE is the recommended grant for modern SPAs and mobile apps — never use the Implicit grant
Passwordless (WebAuthn/FIDO2) is the future direction — phishing-resistant, hardware-bound keys, excellent UX
Session rotation (regenerate ID periodically) limits the window for hijacked sessions
Log all authentication failures — a spike in failures indicates credential stuffing or brute force