What are the main advantages of cookie-based authentication?

The two usually cited: you authenticate only once per visit, and it's simple and well-understood. But session cookies have more going for them — above all the server-side control that stateless tokens give up.

The two headline upsides:

Beyond those two — most of these flow from one fact: the cookie is just an opaque session ID, while the real state lives on the server.

• Instant revocation & server-side control — you can kill a session immediately (logout, "log out everywhere", lock a compromised account). Stateless tokens (JWTs) stay valid until they expire unless you bolt on a denylist.
• No sensitive data on the client — the cookie carries a random ID, not user data or claims; the payload stays tiny and you can change server-side state without reissuing anything to the browser.
• Browser-native & automatic — the browser attaches the cookie to every matching request with zero client-side JavaScript, so it works even with JS disabled.
• XSS-resistant storage — marked HttpOnly, the cookie is invisible to JavaScript, so an XSS bug can't read it out (unlike a token sitting in localStorage); Secure and SameSite add HTTPS-only transport and CSRF hardening.
• Central session management — the server can list active sessions, expire idle ones, and cap concurrent logins.

These are why it was long the state-of-the-art default for web login. The trade-off (see the disadvantages card): that automatic sending is exactly what enables CSRF, and server-side sessions are state you must store and scale.

Tip: The deepest advantage is revocability — a server-side session can be torn down the instant you need to. That single property is the most common reason teams keep cookies instead of moving to stateless tokens.

Go deeper:

• OWASP Session Management Cheat Sheet — server-side session control, revocation, and secure cookie attributes.
• Set-Cookie (MDN) — the HttpOnly, Secure, and SameSite flags behind the security advantages above.