Understanding Authentication, Authorization, and Tokens: From Cookies to JWT

Authentication

Authentication verifies a user's identity, e.g., matching a fingerprint template before granting access.

Authorization

Authorization grants a third‑party application permission to access specific user resources, such as photo or location access.

Credentials

Credentials are the medium that identifies an accessor, ranging from physical ID cards to web tokens issued after a successful login.

Cookie

Because HTTP is stateless, servers use cookies (small data stored on the client) to track sessions. Cookies are domain‑bound, non‑cross‑origin, and limited to about 4 KB.

Session

A session records server‑side state. The server creates a session, returns a SessionID to the browser, which stores it in a cookie. Subsequent requests include the cookie, allowing the server to retrieve the session data.

Cookie vs. Session

Security: Sessions are stored server‑side and are therefore more secure.

Data type: Cookies store only strings; sessions can store any data type.

Lifetime: Cookies can persist long‑term; sessions usually expire quickly or on browser close.

Size: Cookies ≤ 4 KB; sessions can hold much larger data but consume server memory.

Token

Access Token

An access token is presented by the client when calling protected APIs. A simple token consists of uid, time, and a sign generated by hashing.

Stateless server design

Good scalability

Supports mobile devices

Secure and cross‑program callable

Refresh Token

A refresh token is used to obtain a new access token without re‑entering credentials, reducing user friction.

Token vs. Session

Tokens enable stateless authentication; the server validates the token using a secret key without storing session data. Sessions store state on the server and require the session ID from the client.

JSON Web Token (JWT)

JWT is a popular stateless authentication solution. It carries claims about the user, is signed with HMAC or RSA, and can be verified without database lookups.

Principle

After a successful login, the server returns a JWT. The client stores it (usually in localStorage or a cookie) and includes it in the Authorization: Bearer <token> header for protected requests.

Authorization: Bearer <token>

Usage

Store JWT in a cookie or localStorage.

Send it in the Authorization header for API calls.

Server validates the signature and extracts claims.

Common Front‑Back Authentication Methods

Session‑Cookie

Token verification (including JWT, SSO)

OAuth 2.0 (open authorization)

Hash Algorithms

Hash functions create a fixed‑size fingerprint of any data, ensuring integrity and enabling verification without exposing the original content.

Fast computation

One‑way (hard to reverse)

Small input changes produce large output changes

Low collision probability with strong hashes (e.g., SHA‑256)

Security Considerations

When Using Cookies

Validate integrity; never store sensitive data like passwords.

Use HttpOnly and set appropriate domain / path.

Limit size to ≤ 4 KB; browsers cap the number of cookies per domain.

When Using Sessions

High concurrent users increase memory usage; clean up expired sessions.

In clustered deployments, session sharing becomes necessary.

When Using Tokens

Store tokens in fast lookup stores such as Redis if database latency is a concern.

Tokens avoid CSRF because they are not sent automatically by browsers.

When Using JWT

Set short expiration times and rotate signing keys to revoke compromised tokens.

Transmit only over HTTPS.

Do not place secret data in an unencrypted JWT.

Distributed Session Sharing Solutions

Session Replication

Serialize session changes on one node and broadcast to all others; provides fault tolerance but adds network load.

Sticky Session / IP Binding

Bind a client IP to a specific server (e.g., Nginx ip_hash); simple but lacks fault tolerance.

Distributed Cache (Redis / Memcached)

Store sessions in a clustered cache, enabling horizontal scaling and cross‑server access.

Database Persistence

Persist sessions to a database to survive server restarts; high traffic can stress the DB.

FAQ

Does closing the browser delete a session? Not automatically. The server retains the session until it expires or is explicitly destroyed (e.g., on logout).