GeneralIntermediate

JWT

JSON Web Token. Open standard (RFC 7519) for passing information between parties as a compact, self-contained JSON object that is digitally signed.

Pronunciation

/dʒɒt/
"jot"
Listen on:Forvo

What is it

JWT stands for JSON Web Token. It is defined in RFC 7519 (IETF, 2015), which suggests pronouncing it like the English word “jot”. It’s one of the most widely used formats for transmitting identity and permission information between systems.

When an API says you need a “token” to authenticate, that token is very often a JWT (opaque tokens also exist).

JWT Structure

A JWT has 3 parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSBHYXJjw61hIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNjQwMDAwMDAwLCJleHAiOjE2NDAwMDcyMDB9.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

(Real Base64URL-encoded header and payload; the signature is illustrative.)

1. Header

Indicates the signing algorithm used:

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

2. Payload

The data we want to transmit:

{
  "sub": "1234567890",
  "name": "Ana García",
  "role": "admin",
  "iat": 1640000000,
  "exp": 1640007200
}

3. Signature

Guarantees the token wasn’t tampered with. Computed over header + payload with a shared secret (HS256) or a private key (RS256, ES256).

How JWT Authentication Works

1. User logs in (email + password)
         ↓
2. Server verifies credentials
         ↓
3. Server generates JWT signed with secret key
         ↓
4. Server sends JWT to client
         ↓
5. Client stores JWT (on the web, ideally in an HttpOnly, Secure cookie)
         ↓
6. On each request, the JWT is sent (cookie or Authorization: Bearer <JWT> header)
         ↓
7. Server verifies signature → if valid, processes the request

JWT Advantages

Advantage Description
Stateless The server doesn’t need to store sessions in the database
Portable The same token works across multiple services
Self-contained The token carries user information — no need to look it up
Verifiable With asymmetric algorithms (RS256/ES256), any service with the public key can verify it without knowing the private key

Standard Payload Fields

Field Name Description
sub Subject User identifier
iss Issuer Who issued the token
aud Audience Who the token is for
exp Expiration When it expires
iat Issued At When it was issued
nbf Not Before When it becomes valid

Security Best Practices

✅ Do:

  • Use short expiration times (exp), combined with refresh tokens
  • Always transmit over HTTPS
  • Store tokens in HttpOnly cookies for web apps (not localStorage, which is exposed to XSS)
  • Always validate signature, exp, iss, and aud, and pin the accepted algorithms on the server (never alg: none)
  • Use asymmetric algorithms (RS256/ES256) when several services verify tokens; HS256 is fine when a single service issues and verifies, with a strong secret

❌ Don’t:

  • Store sensitive data in the payload (in a signed JWT it’s only Base64URL-encoded, not encrypted)
  • Create tokens that never expire
  • Transmit over unencrypted HTTP

JWT vs Traditional Sessions

Aspect Traditional Session JWT
Storage On server (DB or Redis) On client (token)
Scalability Requires shared sessions Any server can verify
Revocation Immediate (delete the session) Complex (wait for expiry or maintain a revocation list)
Size Small ID Larger token
Best for Traditional web apps APIs, microservices, mobile apps
  • API - APIs use JWT to authenticate who makes each request
  • REST - REST APIs use JWT in the Authorization header
  • Shift-Left Security - Token security must be thought through from design time
  • Microservices - JWT allows multiple services to validate identity without central coordination

Additional Resources:

Related articles

All terms