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, so mechanisms like cookies, sessions, and tokens are needed to associate multiple client requests.

What is Authentication?

Authentication verifies the identity of the user, proving that you are you . The most common method is username and password, but other methods include SMS, QR code, gesture password, email, ID number, one‑time passwords, and biometric features such as fingerprint, voice, or iris.

SMS verification

QR code scanning

Email verification

National ID number

One‑time password based on time series

Biometric authentication

High‑security scenarios often use multi‑factor authentication, combining several methods.

What is Authorization?

Authorization grants third‑party access to user resources. It is commonly implemented via session, cookie, or token mechanisms that store the user's permission information.

Session mechanism – a server‑side session holds authorization data.

Cookie mechanism – a cookie stored in the browser holds authorization data.

Token (e.g., JWT) – a signed token carries authorization information.

What is a Cookie?

Cookie Characteristics

Designed to compensate for HTTP's lack of state management.

Stored on the client; the browser sends it with subsequent requests to the same server.

Bound to a single domain (including sub‑domains) and cannot be accessed across domains.

Setting a Cookie

The server sends a Set-Cookie header in the HTTP response. The cookie 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 includes a Set-Cookie header.

(3) Browser stores the cookie locally and includes it in the next request.

(4) Server receives the request with the cookie and can associate it with prior interactions.

Common Cookie Attributes

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

(2) domain – specifies the domain the cookie belongs to; defaults to the current domain.

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

(4) expires – the GMT expiration time after which the cookie becomes invalid.

(5) max-age – seconds until expiration; overrides expires . Positive values set a lifetime, negative values make the cookie temporary, and zero deletes it.

(6) HttpOnly – when set, 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 a user has with a web application from the moment the browser is opened until it is closed.

Session records server‑client state.

Stored on the server (files, databases, or caches).

Usually implemented using a cookie that holds a sessionId which the server uses to retrieve the session data.

Session Workflow

(1) User logs in; server validates credentials, 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 the session exists.

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

Difference Between Cookie and Session

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

Security : Cookies are less secure because they are stored locally and can be intercepted.

Size : A single cookie is limited to about 4 KB and browsers limit the number of cookies per site; sessions have no such strict size limit.

Lifespan : Cookies can be persistent; sessions typically expire when the browser is closed or after a short inactivity period.

What is a Token?

A token is a credential used to verify a user's identity, often called a "token" or "access token".

Typical token composition includes a user identifier (uid), a timestamp, and a cryptographic signature.

Token characteristics: stateless, extensible, mobile‑friendly, cross‑program callable, and secure.

Stateless and scalable.

Supports mobile devices.

Enables cross‑service calls.

Provides security when properly signed.

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 (e.g., in an HTTP header).

4) Server validates the token and, if successful, returns the requested data.

Token can be sent in the HTTP Header.

Token‑based authentication is stateless on the server side.

Using token verification reduces server storage pressure compared to sessions.

What is JWT?

JWT (JSON Web Token) is a standardized token format defined by RFC 7519.

It consists of three Base64‑encoded parts: header, payload, and signature.

Header – declares the token type (JWT) and the signing algorithm (e.g., HMAC‑SHA256).

Payload – contains registered claims, public claims, and private claims with the actual data.

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

Important JWT characteristics:

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

Protect the secret key used for signing.

Prefer HTTPS to prevent token interception.

Summary

In modern micro‑service architectures, large websites tend to avoid session‑based stateful designs.

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 only validates the token using a secret, trading time for space and relieving server load, though it makes server‑side session control more challenging.

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