Understanding HTTP Statelessness, Authentication, Authorization, Cookies, Sessions, and JWT

HTTP Is a Stateless Protocol

Stateless means each request is independent and has no knowledge of previous requests, similar to a conversation where participants do not remember earlier statements.

Because HTTP lacks memory, mechanisms like cookie , session , and token are required to associate multiple client requests.

Authentication

Authentication verifies the identity of the requester, proving that you are you . The most common method uses a username and password, but other methods include mobile SMS, QR code scanning, gesture passwords, email verification, ID numbers, one‑time passwords, and biometric factors such as fingerprint, voice, or iris.

High‑security scenarios often employ multi‑factor authentication, combining several methods to strengthen identity verification.

Authorization

Authorization grants a third party permission to access user resources. It is typically implemented via:

Session mechanism that stores authorization information in a server‑side session.

Cookie mechanism that keeps authorization data in a browser cookie.

Token (JWT) mechanism that carries authorization claims.

What Is a Cookie?

Cookie Characteristics

cookie was originally designed to compensate for HTTP's lack of state management.

cookie is stored on the client: the server sends a small piece of data to the browser, which includes it in subsequent requests to the same server.

cookie is domain‑bound and cannot be accessed across different domains.

Setting a Cookie

The server sends a cookie to the client via the HTTP response header Set-Cookie . The format is:

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

Cookie Workflow

(1) Browser sends a request to the server.

(2) Server responds and sets a cookie.

(3) Browser stores the cookie locally; subsequent requests include the cookie.

(4) Server processes the request using the cookie.

Common Cookie Attributes

(1) name=value – the key‑value pair that defines the cookie.

(2) domain – the domain for which the cookie is valid; defaults to the current domain.

(3) path – the URL path under which the cookie is sent; default is "/".

(4) expires – the expiration date in GMT; after this time the cookie becomes invalid.

(5) max-age – defined in seconds, takes precedence over expires . Positive values set a lifetime, negative values create a session‑only cookie, and zero deletes the cookie.

(6) HttpOnly – when set, client‑side JavaScript cannot read the cookie.

(7) secure – when true, the cookie is sent only over HTTPS.

What Is a Session?

A session represents a series of interactions between a user’s browser and the server, lasting until the browser is closed or the session expires.

(1) Session Characteristics

Records state on the server side.

Usually stored in files, databases, or caches.

Implemented via a cookie that holds a sessionId linking the client to the server‑side session data.

(2) Session Workflow

(1) User logs in; server creates a session and sends a sessionId in a cookie.

(2) Subsequent requests automatically include the cookie; the server retrieves the session using the sessionId and proceeds.

If cookies are disabled, the sessionId can be passed via URL rewriting.

Cookie vs. Session

Storage : Cookie data resides on the client, session data on the server.

Security : Cookies are vulnerable to theft and replay attacks; sessions are generally more secure because data stays server‑side.

Size : Cookies are limited to about 4 KB per entry; sessions have no such strict size limit.

Lifetime : Cookies can be persistent; sessions typically expire when the browser closes or after a short inactivity period.

What Is a Token?

(1) Token Composition

A token (or "令牌") is a credential that proves a user’s identity. A simple token contains a user ID, a timestamp, and a cryptographic signature.

(2) Token Features

Stateless and extensible.

Suitable for mobile devices.

Supports cross‑service calls.

Provides security when properly signed.

(3) Token Workflow

1) Client logs in with credentials.

2) Server authenticates, generates a token, and returns it to the client (often stored in a cookie or localStorage).

3) Client includes the token in subsequent requests, typically in the HTTP Authorization header.

4) Server validates the token and, if valid, processes the request.

Notes:

Tokens can be sent in HTTP headers.

Token‑based authentication is stateless on the server side.

Offloading session data to the token reduces server load and database queries.

What Is JWT?

(1) JWT as a Standardized Token

JWT (JSON Web Token) is a widely adopted standard for tokens, defined in RFC 7519.

It carries claims about the user and can be used by resource servers to grant access.

(2) JWT Structure

JWT consists of three parts:

Header – specifies the token type and signing algorithm (e.g., HS256).

Payload – contains registered, public, and private claims.

Signature – generated from the Base64‑encoded header, payload, and a secret key.

(3) JWT Characteristics

Do not store sensitive data in the payload, as it is readable by the client.

Protect the secret key used for signing.

Prefer HTTPS to prevent token interception.

Summary

In today’s micro‑service architectures, large websites tend to avoid server‑side sessions to achieve statelessness.

Sessions are simple but require server‑side storage and sharing across clusters, which adds overhead.

JWT (token) stores session information on the client; the server validates it using a secret, trading computation time for reduced storage, thereby easing server clustering at the cost of increased control complexity.

Choose the solution that best fits your project’s security and scalability requirements.

-- End --