In a nutshell Authentication is proving who you are; a session is how the site remembers it afterwards so you don't re-enter your password on every click. Both are prime targets: break authentication and you're someone else; steal a session and you're them without ever knowing the password.
Authentication vs authorization
Authentication (authN)
- who are you?
- proving identity: password, code, key
- done once, at login
Authorization (authZ)
- what may you do?
- checking permissions per action
- checked every request
A huge class of bugs is doing authN but forgetting authZ — you're logged in as a normal user, but the server never checks you're not allowed at /admin.
How a session works
HTTP forgets you between requests (it's stateless). So after login the server issues a session token in a cookie; your browser sends it on every request; the server maps it back to "the person who logged in."
That token is your identity for the rest of the visit. Whoever holds a valid token is treated as that user — no password needed. That single fact drives most session attacks.
Analogy — a wristband at an event. You show ID once at the gate (authenticate) and get a wristband (session token). Inside, nobody re-checks your ID — the band is enough. Steal or forge a band and you walk in as someone else.
The attacks
| Target | Attack | Stopped by |
|---|---|---|
| authentication | brute-force / spraying (hydra) |
rate-limit, lockout, MFA |
| authentication | credential stuffing (reused leaked pairs) | MFA, breach-password checks |
| authentication | default/weak creds (admin/admin) |
strong password policy |
| session | hijacking (steal token via XSS/sniff) | HttpOnly, HTTPS |
| session | predictable tokens | long random tokens |
| session | no expiry / logout doesn't invalidate | real expiry, server-side revoke |
| session | CSRF (use victim's session without stealing it) | CSRF tokens, SameSite cookies |