Session vs Token Authentication – Java Backend Fresher Interview

Session-based authentication stores a login record on the server and gives the client a session ID, commonly in a cookie. Each request presents that ID and the server loads the saved security context. A cluster can use a shared session store or another replication or routing design, so sessions are not limited to one server.

Token-based authentication is a larger category. An opaque token is a reference that normally needs introspection. A self-contained JWT can be validated locally from trusted keys and claims without an HTTP-session lookup. The application may still load current roles, account status, or revocation data, so “the server stores nothing” is too strong.

For example, a browser shopping site might keep JSESSIONID in an HttpOnly, secure cookie and delete the server-side session at logout. A mobile API might accept a short-lived access token in Authorization: Bearer ... and use a refresh-token record so stolen or logged-out credentials can be revoked.

The trade-off is where state and lifecycle work live. Sessions are easy to invalidate centrally but need session infrastructure. Self-contained tokens reduce session lookups but need careful expiry, key rotation, storage, and revocation policy. CSRF depends on transport: any authentication cookie can be sent automatically, while a bearer token explicitly placed in an Authorization header is not ambient.