JSON Web Tokens for Stateless Authentication

Historical note: this article was first published in 2016. JWT remains widely used, but a secure implementation also needs strict claim validation, short expiration times, safe key management, and a deliberate strategy for revocation. A signed payload is readable; it is not encrypted.

A JSON Web Token, or JWT, is a compact standard for carrying claims between two parties. After authenticating a user, a server can create a token containing an identifier and other limited information. The client returns that token with later requests, allowing any server that trusts the signature to verify it without relying on a local session.

Why use a token?

A traditional login often creates a server-side session containing the user's identifier. That becomes more complicated when several application servers share the traffic. If a session is created on server A and the next request reaches server B, the state must either be replicated, stored centrally, or kept on the same server through sticky routing.

An opaque API token has a similar trade-off. The server can store the token in a database and look it up on every request, but that creates shared state and another lookup on the authentication path.

A JWT takes a different approach. The claims needed to identify the session are placed inside the token and protected by a cryptographic signature. The client may read those claims, but changing them invalidates the signature. A receiving server can therefore verify the token locally, provided it has the correct verification key and validates the required claims.

That does not remove every database query from an application. It only means that basic token verification does not require a lookup. Authorisation rules, account status, revocation, and current data may still require server-side state.

The three parts of a JWT

A token contains three Base64URL-encoded sections separated by dots:

Header

The header is a small JSON object describing the token type and signing algorithm. Once encoded, it becomes the first section of the token.

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

Payload

The payload contains claims about the subject and the token itself. The standard defines registered claims such as sub (subject), exp (expiration), iss (issuer), and aud (audience), while applications may add carefully chosen claims of their own.

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

Base64URL is an encoding, not encryption. Anyone holding the token can decode this section, so secrets and unnecessary personal information do not belong in it.

Signature

The signature lets the receiver detect changes and verify who issued the token. With an HMAC algorithm such as HS256, the server signs the encoded header and payload using a shared secret. With an asymmetric algorithm, the issuer signs using a private key and other services verify using the corresponding public key.

The server returns the finished token to the client. On each protected request, the client sends it back—commonly in an Authorization: Bearer header. The server verifies the signature and then checks claims such as expiration, issuer, audience, and subject before trusting it.

Is it secure?

JWT is a format, not an authentication architecture by itself. Its security depends on the surrounding decisions:

• use a maintained library and explicitly allow only the expected algorithms;
• keep signing keys strong, private, rotated, and separated by environment;
• validate exp, nbf, iss, and aud where applicable;
• use HTTPS, because a valid token can still be stolen in transit or from an unsafe client;
• keep tokens short-lived and plan how compromised sessions will be revoked;
• store tokens in a way that accounts for XSS and CSRF risks in the specific application.

JWT can be useful when several services need to verify the same identity without sharing local session state. It should be chosen because that property fits the system—not simply because tokens appear more modern than sessions.

References

• JWT.io introduction and debugger
• RFC 7519: JSON Web Token