Understanding Authentication, Authorization, Sessions, Cookies, Tokens and JWT

What is Authentication?

Authentication is the process of verifying a user's identity, such as matching a fingerprint or confirming a username/password, email link, or SMS code, to ensure the user is who they claim to be.

What is Authorization?

Authorization determines what actions an authenticated user is allowed to perform, controlling access to resources based on roles or permissions.

What are Credentials?

Credentials are the medium (e.g., certificates, tokens) that prove a user's identity and are required for both authentication and authorization.

Cookie and Session

HTTP is stateless, so servers use cookies or sessions to track user state. Cookies are stored client‑side and sent with each request, while sessions store state server‑side and reference the session ID via a cookie.

Cookie attributes include domain, path, expiration, and size limits (≈4 KB).

Session characteristics include server‑side storage, ability to hold any data type, and typically shorter lifetimes.

Cookie vs Session

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

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

Expiration: Cookies can be long‑lived; sessions usually expire when the browser closes or after a timeout.

Size: Cookies are limited to ~4 KB, sessions can hold much larger data.

Session Pain Points in Distributed Systems

When multiple servers handle requests, a session created on server A may be unavailable on server B, causing login failures.

Common solutions:

Session replication – copy session data to all nodes (high network overhead).

Sticky sessions – route a user's requests to the same server using IP‑hash or cookie‑based affinity.

Session sharing – store sessions in a shared cache such as Redis or Memcached.

Token Overview (Stateless Authentication)

Instead of storing session state, the server issues a signed token (e.g., JWT) after successful login. The client stores the token (in localStorage or a cookie) and sends it with each request, typically in the Authorization: Bearer <token> header.

Token structure:

Header – specifies the signing algorithm.

Payload – contains claims such as user ID and expiration.

Signature – generated by the server using a secret key.

Advantages: cross‑domain support, no server‑side state, easy scaling. Drawbacks: longer size, potential security risks if stored insecurely, and difficulty revoking tokens before expiration.

Refresh Token

A short‑lived access token can be renewed using a refresh token, reducing the need for users to re‑authenticate.

JWT Overview

JSON Web Token (JWT) is a popular stateless authentication mechanism that encodes claims in a signed JSON object. It can be used for single sign‑on (SSO) and API protection.

Typical JWT flow:

User logs in with credentials.

Server validates credentials and returns a JWT.

Client stores the JWT.

For protected resources, the client includes the JWT in the Authorization: Bearer <token> header.

Server verifies the signature and extracts claims without needing a database lookup.

Common Backend Authentication Methods

Session‑Cookie

Token verification (including JWT, SSO)

OAuth 2.0

Common Encryption Algorithms

Irreversible (hash) algorithms: MD5, SHA, HMAC – used for password storage and integrity checks.

Reversible symmetric algorithms: AES, DES, 3DES, Blowfish – used for encrypting sensitive data that must be decrypted.

Asymmetric algorithms: RSA, DSA, ECC – used for digital signatures and key exchange.

Security Considerations

Never store passwords in plain text; always hash with a strong algorithm.

Use HTTPS to protect token transmission.

Set appropriate cookie flags (HttpOnly, Secure) and limit cookie size.

Be aware that JWTs cannot be revoked easily; keep their lifespan short.