Understanding Authentication, Authorization, and Tokens: From Cookies to JWT
This article explains the fundamentals of authentication, authorization, and credentials, compares cookies, sessions, and tokens, introduces JWT structure and usage, discusses common security concerns, and outlines practical solutions for distributed systems and modern web applications.
Authentication, Authorization, and Credentials
What is Authentication?
Verification of a user's identity, e.g., fingerprint check or username/password login.
In the web, authentication methods include password login, email login links, and SMS verification codes.
Sessions store login state to avoid repeated authentication.
What is Authorization?
Determines who can do what on which resources; it follows successful authentication.
Users grant third‑party apps specific permissions (e.g., access to photos or location).
Common implementations use role‑based (RBAC) or resource‑based (ABAC) access control.
What are Credentials?
Credentials are the medium (certificate) that marks a user's identity.
Examples: physical ID cards, digital identity documents, or tokens issued after login.
Web applications issue a token (often stored in a cookie) after successful login.
Cookie and Session
What is a Cookie?
HTTP is stateless; cookies are small pieces of data stored on the client and sent with each request to maintain state.
Cookies are domain‑bound and can be shared between primary and sub‑domains.
Important cookie attributes
What is a Session?
Session records server‑client interaction state, typically stored on the server with a SessionID saved in a cookie.
When a request arrives, the server reads the SessionID from the cookie to retrieve the corresponding session data.
Session authentication flow:
User sends initial request; server creates a Session.
Server returns the unique SessionID.
Browser stores SessionID in a cookie.
Subsequent requests include the cookie; server validates the SessionID.
Differences between Cookie and Session:
Security: Session data resides on the server, making it more secure than client‑side cookies.
Data type: Cookies store only strings; Sessions can store any data type.
Lifetime: Cookies can be long‑lived; Sessions usually expire when the browser closes or after a timeout.
Size: Cookies are limited to ~4 KB; Sessions have much larger storage capacity.
Session Pain Points
In a multi‑server environment, a user’s request may be routed to a different server that does not have the original session, causing login loss.
Common solutions:
Session replication : copy session data to all nodes (adds redundancy and network overhead).
Sticky sessions : use load balancer (e.g., Nginx ip_hash) to bind a client’s IP to a specific server (lacks fault tolerance).
Session sharing : store sessions in a distributed cache such as Redis or Memcached (adds a lookup cost but scales well).
Token and JWT (Cross‑Domain Authentication)
Token Overview (no session)
After login, the server issues a token that the client stores locally (e.g., in localStorage) and sends with each request in the Authorization header.
Token structure:
Header : specifies signing algorithm.
Payload : contains user ID, expiration, and other non‑sensitive claims.
Signature : server signs header+payload with a secret key.
Verification process:
Server extracts header and payload, recomputes the signature, and compares it with the token’s signature.
If valid, the payload provides the user ID without additional database lookups.
Advantages:
Stateless; no server‑side storage required.
Works across domains; avoids CSRF attacks.
Suitable for mobile clients.
Token vs Session
Token is sent in headers, not cookies, eliminating same‑origin restrictions.
Session stores state on the server; token is self‑contained.
JWT Overview
JSON Web Token (JWT) is a popular cross‑domain authentication solution.
JWTs are signed (HMAC or RSA) and can be verified without server‑side storage.
JWT authentication flow:
User logs in with credentials.
Server returns a JWT.
Client stores JWT (localStorage or cookie).
Client includes Authorization: Bearer <token> in protected requests.
Server validates the JWT signature and grants access.
Authorization: Bearer <token>Using JWT
Place JWT in the Authorization header (Bearer scheme) for API calls.
Can also send JWT in POST body or as a URL query parameter.
GET /calendar/v1/eventshttp://www.example.com/user?token=xxxCommon Front‑End/Back‑End Authentication Methods
Session‑Cookie
Token verification (including JWT, SSO)
OAuth 2.0
Common Encryption Algorithms
Irreversible (Hash)
MD5, SHA, HMAC – used for password storage and data integrity.
Reversible (Symmetric)
AES, DES, 3DES, Blowfish, etc. – used for encrypting sensitive data that must be decrypted.
Asymmetric Encryption
RSA, DSA, ECC – used for digital signatures and key exchange.
Security Considerations
Never store passwords in plain text; always hash them.
Use strong hash algorithms; avoid MD5 and SHA‑1 for passwords.
Protect tokens and cookies with HTTPS and, where appropriate, HttpOnly and Secure flags.
Architect's Guide
Dedicated to sharing programmer-architect skills—Java backend, system, microservice, and distributed architectures—to help you become a senior architect.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.