Session Tokens - Temporary Authentication Credentials

About 2 min read

A session token is a temporary identifier issued by the server or client to maintain a user's logged-in state. HTTP is inherently a stateless protocol, with each request being an independent connection. A session token compensates for this statelessness, providing the mechanism by which the server can determine that "this request comes from user A who logged in earlier." In web application security, it is one of the most important elements, on par with authentication itself.

HTTP Statelessness and Session Management

In the era of HTTP/1.0, the web was a simple protocol for retrieving documents. It was designed so that a request and response completed in a one-to-one exchange, with no context carried before or after. However, as shopping carts on e-commerce sites and login functionality became required, "retaining state" became indispensable. In 1994, Lou Montulli of Netscape invented the cookie, creating a mechanism that lets the browser store an identifier issued by the server. This was the origin of session management.

Today's session management is broadly divided into two approaches: server-side sessions and token-based sessions. Which one to choose is determined by the application's architecture and security requirements.

Cookie-Based vs Token-Based (JWT)

With server-side sessions, the server generates a session ID and stores the corresponding session data on the server side (in memory, a database, Redis, etc.). Only the session ID is passed to the client via a cookie, and the client sends this ID with subsequent requests. Because the server manages the state, sessions can be invalidated (logout, forced disconnection) instantly.

On the other hand, token-based approaches, exemplified by JWT (JSON Web Token), embed the state within the token itself, including user information and an expiration. Because the server completes authentication simply by verifying the token's signature, no session store is needed, and scalability is excellent. However, there is a fundamental challenge: it is difficult to invalidate an already-issued JWT immediately. Even if a user changes their password, an existing JWT can keep being used until it expires. To mitigate this problem, it is common to combine a short-lived access token (around 15 minutes) with a long-lived refresh token.

Attacks Against Sessions

Session tokens are an ideal target for attackers. Session hijacking is an attack that steals a valid session token to impersonate the user. A representative technique is exploiting an XSS vulnerability to read cookies from JavaScript.

Session fixation is a technique in which the attacker gets the victim to use a session ID that the attacker prepared in advance. When the victim logs in with that session ID, the attacker can access the authenticated state with the same session ID. As a countermeasure, regenerating the session ID upon successful login (session re-issuance) is essential. CSRF attacks are also predicated on the existence of session tokens and are closely related to session management. You can find concrete countermeasures in session hijacking countermeasures and defenses against session token theft.

Strengthening Security with Cookie Attributes

When managing session tokens with cookies, proper attribute settings are the key to security. The Secure attribute restricts cookies to be sent only over HTTPS connections, and combined with encryption in transit, prevents eavesdropping. The HttpOnly attribute prohibits access to cookies from JavaScript, preventing token theft via XSS. The SameSite attribute controls cookie transmission during cross-site requests, reducing the risk of CSRF attacks.

These three attributes are sometimes called "the three sacred treasures of session cookies," and missing even one of them can become a security hole. Web security books on Amazon also explain that configuring cookie attributes is a fundamental topic covered first.

Designing Token Expiration

Designing the expiration is itself a trade-off between security and convenience. If it is too short, users are forced to log in again frequently; if it is too long, the damage from a token leak grows larger. As a general guideline, high-security services such as banks set 15-30 minutes, typical web services set 1-24 hours, and convenience-oriented services like social networks set anywhere from several weeks to several months. Browser password safety is also an important topic related to session management.