JWT Tokens: How They Work and Security Best Practices

JSON Web Tokens (JWT) are an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. They are widely used for authentication and authorization in modern web applications.

JWT Structure

A JWT consists of three parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1. Header

{

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

Base64Url encoded. Specifies the signing algorithm and token type.

2. Payload (Claims)

{

  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "role": "admin"
}

Contains the claims (statements about the user and metadata).

Standard Claims:

• iss (issuer): Who issued the token
• sub (subject): Who the token is about
• exp (expiration): When the token expires
• iat (issued at): When the token was created
• aud (audience): Who the token is intended for

3. Signature

HMACSHA256(

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

Signing Algorithms

Symmetric (HMAC)

• HS256: HMAC with SHA-256
• Same secret key for signing and verification
• Simpler but the secret must be shared

Asymmetric (RSA/ECDSA)

• RS256: RSA with SHA-256
• ES256: ECDSA with SHA-256
• Private key signs, public key verifies
• Better for microservices (public key can be distributed)

How JWT Authentication Works

1. User sends credentials (username/password) to the server

2. Server validates credentials and creates a JWT

3. JWT is sent back to the client

4. Client includes JWT in subsequent requests (usually in the Authorization header)

5. Server validates the JWT signature and processes the request

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Security Best Practices

DO:

• Set short expiration times (exp)
• Use HTTPS for all JWT transmissions
• Validate all claims (especially exp, iss, aud)
• Use asymmetric algorithms for public-facing APIs
• Store tokens securely (HttpOnly cookies preferred)

DON'T:

• Store sensitive data in the payload (it is only Base64 encoded, not encrypted)
• Use the none algorithm in production
• Store JWTs in localStorage (vulnerable to XSS)
• Create tokens that never expire
• Trust the token without verifying the signature

JWT vs Sessions

FeatureJWTSessions

|---------|-----|----------|

StorageClient-sideServer-side ScalabilityExcellent (stateless)Requires shared session store RevocationDifficultEasy SizeLarger (payload in token)Small (session ID only)

Common Vulnerabilities

1. Algorithm confusion: Accepting none algorithm

2. Key confusion: Using RS256 public key as HMAC secret

3. Weak secrets: Using predictable signing keys

4. No expiration: Tokens valid forever

Decode and inspect JWT tokens with our JWT Decoder tool.