Understanding JWT: How Stateless Tokens Enable Scalable Cross‑Domain Authentication

Why traditional session authentication struggles with scaling

Web services typically authenticate users by storing a session ID in a cookie after the user submits a username and password. The server keeps session data (user role, login time, etc.) and validates the session ID on each request. In a single‑server setup this works, but in a clustered or cross‑domain architecture every server must share session state, which hurts scalability and creates a single point of failure.

JWT principle

Instead of persisting session data, the server creates a JSON object containing the necessary claims, signs it, and returns it to the client. The client includes this token in every subsequent request, allowing the server to verify identity solely from the token.

JWT data structure

A JWT is a single long string composed of three Base64URL‑encoded parts separated by dots ( .):

Header.Payload.Signature

Header

The header is a JSON object that describes the token type and signing algorithm, e.g.:

{
  "alg": "HS256",
  "typ": "JWT"
}

The alg field specifies the algorithm (default HMAC‑SHA256) and typ is always JWT. The JSON is then Base64URL‑encoded.

Payload

The payload is another JSON object that carries the actual claims. JWT defines seven standard fields (iss, exp, sub, aud, nbf, iat, jti) and developers can add private fields as needed, for example:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

Note that the payload is not encrypted by default, so secret information should never be placed here. It is also Base64URL‑encoded.

Signature

The signature protects the header and payload from tampering. With a secret key known only to the server, the signature is computed as:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

The resulting signature is Base64URL‑encoded and concatenated with the header and payload using dots.

Base64URL encoding

Base64URL is a URL‑safe variant of Base64: the characters + and / are replaced by - and _, and padding = is omitted. This makes the token safe to include in URLs.

How to use a JWT

Clients can store the token in a cookie or in localStorage. For each request the token should be sent in the Authorization header to avoid cross‑origin cookie issues: Authorization: Bearer <token> Alternatively, the token can be placed in the request body for cross‑domain POST calls.

Key characteristics and best practices

JWTs are stateless; the server does not keep session data.

They are not encrypted by default, so never embed confidential data.

They can reduce database lookups by carrying necessary claims.

Revocation is difficult because the server cannot invalidate a token before its expiration; short lifetimes and refresh mechanisms are recommended.

If a token is leaked, an attacker gains all its privileges; therefore use HTTPS and keep token lifetimes brief.

Reference links

Introduction to JSON Web Tokens – Auth0

Sessionless Authentication using JWTs (Node + Express + Passport) – Bryan Manuele

Learn how to use JSON Web Tokens – dwyl