Understanding Cookies, Sessions, and Tokens: When and How to Use Each

When performing API testing, you often encounter request parameters named token, but many testers are still unclear about the differences between token, cookie, and session.

Cookie

A cookie is a piece of data permanently stored by the browser. It is generated by the server, sent to the browser, and saved as a key‑value pair in a local file; the browser sends it back on subsequent requests to the same domain. Browsers limit the number and size of cookies per domain for security and storage reasons.

Session

A session represents a conversation between client and server. The server assigns a unique identifier to each client and stores the user's information on the server side, typically using a cookie to carry the session ID. Sessions are more secure than cookies because the data resides on the server, but they can be lost when load‑balancing across multiple servers unless session sharing is implemented.

Token

Tokens were introduced to avoid repeated username/password verification on every request. The server generates a token (often a string containing user ID, timestamp, and a signed hash) after the first login; subsequent requests include this token, reducing database queries and server load.

Traditional Authentication

Because HTTP is stateless, a typical approach stores a login record on the server, returns its ID to the client, and saves that ID in a cookie. The server validates the cookie on each request to identify the user. This method relies on server‑side session storage, which may be kept in memory, disk, or a database.

Token‑Based Authentication

The workflow is:

Client sends username and password to log in.

Server validates credentials.

On success, the server issues a token and returns it to the client.

Client stores the token (e.g., in a cookie or local storage).

For each subsequent request, the client includes the token.

Server verifies the token and, if valid, returns the requested data.

In mobile apps, the token is often stored securely and sent in the request body over HTTPS.

Token Storage Recommendations

Storing tokens in a database can be slow; alternatives include in‑memory tables, Memcached, Redis, or OpenResty variable dictionaries. Because tokens are lightweight (e.g., 32‑character strings), memory‑based storage is usually sufficient, even for millions of users.

Client‑Side Token Security

Tokens should be encrypted at rest and transmitted over HTTPS. Combining the request URL, timestamp, and token with a salted signature adds protection against replay attacks. Providing a mechanism for users to manually expire tokens can mitigate damage if a token is compromised.

Cookie vs. Session vs. Token

Cookie data resides on the client, while session data lives on the server. Cookies are less secure and limited in size; sessions consume server resources. Tokens offer stateless authentication, are suitable for RESTful APIs, and can carry both authentication and authorization information.

Common Misconceptions

Closing a browser does not automatically delete a session; the server retains the session until it expires or is explicitly removed. Session IDs are often stored in session cookies, which disappear when the browser closes, creating the illusion that the session ended.