Understanding Tokens, JWT, and Authentication Security

Token Overview (no session) – A token is generated by the server after a user provides credentials, stored client‑side (usually in localStorage or the Authorization header), and sent with each request for stateless authentication. It consists of a header (signing algorithm), a payload (user ID, expiration, etc.), and a signature generated with a secret key.

The server validates a token by recomputing the signature from the header and payload and comparing it to the token's signature; if they match, the token is considered legitimate and the payload provides the user ID without needing a server‑side session store.

Benefits of Token‑Based Authentication

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

Supports cross‑origin access where cookies cannot be shared.

Stateless and shareable across multiple servers.

Mitigates CSRF attacks because the token is not automatically sent by the browser.

Easy to extend to mobile clients where cookies are unavailable.

CSRF Explanation – An attacker tricks a logged‑in user’s browser into sending a request that includes the user’s session cookie, potentially performing unauthorized actions. Tokens avoid this because they are not automatically attached to requests.

Same‑Origin Policy – Browsers only allow scripts to read/write resources from the same protocol, domain, and port unless explicitly authorized, which is the root cause of cross‑origin issues.

Cross‑Origin Solutions

Reverse proxy (e.g., Nginx) to forward requests.

JSONP for static resources.

Adding appropriate CORS response headers.

Access Token vs. Refresh Token

Access tokens have short lifespans; when expired, a refresh token can obtain a new access token without re‑authenticating the user.

Refresh tokens are stored server‑side and are only validated when a new access token is requested.

Token Drawbacks

Tokens can be long, increasing request size and potentially exceeding cookie limits.

If stored in localStorage, they are vulnerable to XSS; they cannot be forcibly revoked before expiration without a blacklist.

JWT Overview – JSON Web Token is a widely used, stateless authentication standard that encodes claims in a JSON object, signed with HMAC or RSA, allowing the server to verify authenticity without database lookups.

Typical JWT workflow:

User logs in with credentials.

Server authenticates and returns a JWT.

Client stores the JWT (localStorage or cookie).

Client includes Authorization: Bearer <token> in subsequent requests.

Server validates the JWT signature and grants access if valid.

JWT can be sent via HTTP headers, request bodies, or query parameters (e.g., http://www.example.com/user?token=xxx).

Common Authentication Methods

Session‑Cookie.

Token verification (including JWT and SSO).

OAuth 2.0.

Common Encryption Algorithms

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

Symmetric encryption : AES, DES, 3DES, Blowfish – same key for encryption and decryption, suitable for protecting sensitive data.

Asymmetric encryption : RSA, DSA, ECC, Diffie‑Hellman – public key encrypts, private key decrypts, commonly used for digital signatures and key exchange.

Overall, token‑based authentication, especially JWT, provides a stateless, scalable, and cross‑origin friendly solution, while understanding its limitations and the underlying cryptographic primitives is essential for building secure systems.