JWT & Secure Token Handling

JWT is a token format often used to carry signed claims between parties. JWT itself is not a complete authentication architecture. Security depends on how tokens are issued, validated, stored, transported, expired, rotated, and revoked or otherwise invalidated.

JWT structure

header.payload.signature

The header describes the algorithm and token type, the payload contains claims, and the signature allows the recipient to verify integrity when using an appropriate signing scheme.

Example claims

{
  "sub": "user-101",
  "iss": "auth-service",
  "aud": "orders-api",
  "exp": 1790000000,
  "scope": "orders.read orders.create"
}

JWT is not encryption

A signed JWT payload is normally readable by whoever possesses the token. Do not put passwords, secrets, or sensitive information into ordinary JWT claims simply because the token is signed.

Access token and refresh token

Some architectures use a short-lived access token plus a longer-lived refresh mechanism. The refresh mechanism should be designed carefully with rotation, reuse detection where appropriate, expiration, and server-side controls.

flowchart TD
A[Login] --> B[Authentication service]
B --> C[Short lived access token]
B --> D[Refresh mechanism]
C --> E[API]
E --> F[Expired]
F --> D
D --> B
B --> C

Storage considerations

Token storage is an architectural security decision. Storing bearer tokens in browser-accessible storage means JavaScript running in the page may be able to read them if an XSS vulnerability exists. A server-managed session using Secure, HttpOnly cookies can reduce token exposure to JavaScript, but it requires correct CSRF defenses and server-side session design.

Authorization header

Authorization: Bearer <access-token>

Token validation

The API should validate signature, issuer, audience, expiration, and relevant authorization claims according to the application's trust model. Never accept a token merely because it decodes successfully.

Logout and revocation

JWT access tokens are often self-contained, so logout does not automatically make an already issued token disappear. Systems can use short expiration, token rotation, server-side session controls, revocation mechanisms, or other architecture-specific approaches.

Expected security behavior

Valid token:
200 OK

Expired token:
401 Unauthorized

Valid identity but missing permission:
403 Forbidden

Tampered signature:
401 Unauthorized

Common mistakes

• Putting secrets into JWT payloads.
• Trusting decoded claims without signature validation.
• Using very long-lived bearer tokens without a reason.
• Logging Authorization headers.
• Assuming logout automatically invalidates every self-contained JWT.

Interview questions

• What is a JWT?
• Is JWT encrypted?
• Access token vs refresh token?
• Where can browser tokens be exposed?
• What must an API validate?
• Why does logout require additional architecture for self-contained tokens?