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

What is Authentication?

In simple terms, authentication is the process of verifying a user's identity, answering the question "who are you?". For example, fingerprint check‑in at work validates that the presented fingerprint matches the stored one.

Online authentication methods include username/password, email login links, and SMS verification codes. Receiving the email or code proves ownership of the account.

After authentication, a session can be created to avoid repeated logins. Sessions are typically implemented with Session IDs or tokens.

What is Authorization?

Authorization determines who can do what. It follows the pattern "who (who) does what (what) and how (how)". After authentication, authorization controls access to specific resources.

Users grant third‑party apps permission to access certain resources, such as photo library or location.

Common implementations are role‑based (RBAC) and resource‑based (ABAC) access control.

What are Credentials?

Credentials are the medium (certificate) that marks a visitor's identity, enabling authentication and authorization.

Historically, documents like the "Zhao Shen Tie" in the Warring States period served as identity certificates, similar to modern ID cards.

In web applications, after a successful login the server issues a token (often stored in a cookie) that represents the user's identity for subsequent requests.

Cookie and Session

What is a Cookie?

HTTP is stateless, so servers use cookies or sessions to maintain state across requests.

Cookies are small pieces of data stored on the client and sent with each request to the same server.

Cookies are domain‑bound; they cannot be accessed by other domains, though subdomains can share them via the domain attribute.

Important cookie attributes

What is a Session?

Session records the state between server and client, indicating whether two requests come from the same browser.

Session data is stored on the server; the Session ID is sent to the client via a cookie.

Session authentication flow:

When the user first requests the server, the server creates a Session.

The server returns a unique SessionID to the browser.

The browser stores the SessionID in a cookie.

On subsequent requests, the browser automatically sends the cookie; the server retrieves the Session using the SessionID.

SessionID acts as a bridge between Cookie and Session, enabling login status verification.

Session‑based authentication is provided by the Servlet specification; developers can use HttpSession methods to manage it.

Cookie vs Session

Security: Session data resides on the server, making it more secure than client‑side cookies.

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

Lifetime: Cookies can persist long‑term; Sessions typically expire when the browser closes or after a timeout.

Size: Cookies are limited to ~4 KB; Sessions can store much larger data but consume server resources.

Session Pain Points

In a multi‑server environment, a user may be directed to different machines, causing session loss. Three common solutions are:

Session replication – copy session data to all nodes (adds redundancy but increases network load).

Sticky sessions – bind a client’s IP to a specific server (simple but lacks fault tolerance).

Session sharing – store sessions in a distributed cache such as Redis or Memcached (preferred for large‑scale systems).

Token and JWT (Cross‑Domain Authentication)

Token Overview (no session)

After login, the server generates a token and returns it to the client, which stores it locally (e.g., in localStorage). Subsequent requests include the token in the Authorization header.

Token structure:

Header: specifies the signing algorithm.

Payload: contains non‑sensitive data such as user ID and expiration time.

Signature: server signs the header and payload with a secret key.

When the server receives a token, it recomputes the signature and verifies it. The payload includes the user ID, eliminating the need to query a session store.

Tokens are typically sent in the Authorization header, not in cookies, which avoids same‑origin restrictions and CSRF attacks.

Token Advantages

Fully managed by the application, bypassing same‑origin policy.

Supports cross‑domain access (cookies cannot).

Stateless, enabling sharing across multiple servers.

Helps prevent CSRF attacks.

Easy to use on mobile platforms where cookies are unavailable.

What is CSRF? An attacker tricks a logged‑in user’s browser into sending authenticated requests to a target site, potentially performing unwanted actions.

Token Drawbacks

Tokens can be long, exceeding cookie size limits.

If stored in localStorage, they are vulnerable to XSS attacks, and they cannot be revoked before expiration without additional server‑side blacklisting.

Access Token vs Refresh Token

Access tokens have short lifetimes; when they expire, a refresh token can obtain a new access token without re‑authentication.

Refresh tokens are stored server‑side (e.g., in a database) and are only validated when a new access token is requested.

Token vs Session Differences

Session data is kept on the server; token data is self‑contained and sent with each request.

Session IDs require server‑side lookup; JWTs can be verified locally using a secret key.

JWT Overview

JSON Web Token (JWT) is a popular cross‑domain authentication solution.

It is a JSON‑based open standard (RFC 7519) for transmitting claims between identity providers and service providers.

JWTs can be signed with HMAC or RSA algorithms, ensuring integrity.

Generating JWT

https://jwt.io/

https://www.jsonwebtoken.io/

JWT Authentication Flow

User submits username/password.

Server validates credentials.

Server issues a JWT.

Client stores the JWT (e.g., in localStorage).

Client includes the JWT in the Authorization: Bearer <token> header for protected requests.

Server verifies the JWT signature and grants access if valid.

Authorization: Bearer <token>

Using JWT

Place the JWT in the Authorization header (Bearer scheme) for protected routes.

Because JWTs are self‑contained, the server does not need to query a database for each request.

JWTs do not rely on cookies, eliminating CORS concerns.

Considerations When Using JWT

JWTs are not encrypted by default; sensitive data should not be placed in the payload.

Since the server does not store session state, revoking a specific JWT before expiration requires additional logic (e.g., a blacklist).

Use HTTPS to protect JWTs in transit.

Common Front‑Back Authentication Methods

Session‑Cookie

Token verification (including JWT and SSO)

OAuth 2.0 (open authorization)

Common Encryption Algorithms

Irreversible (Hash) Algorithms

Used for password storage; examples include MD5, SHA, HMAC.

Reversible Encryption

Symmetric Encryption

Same key for encryption and decryption; examples: AES, DES, 3DES.

Asymmetric Encryption

Public key encrypts, private key decrypts; examples: RSA, DSA, ECC.