JWT Generator

JWTs in production — the spec, the algorithms, and the attacks you need to know

JSON Web Tokens are the connective tissue of modern auth. OAuth 2.0 access tokens, OpenID Connect ID tokens, AWS Cognito sessions, Auth0 sessions, Firebase Auth, Cloudflare Zero Trust, and every framework's "auth helper" all hand you JWTs. The spec is small (RFC 7519) and the format is elegant — but the historical CVEs against JWT implementations are extensive, and most of them are caused by misuse rather than spec flaws. This guide walks through the structure, the algorithm choices that matter, the alg=none and key-confusion attacks every junior backend engineer needs to know about, and the rotation patterns that production systems actually use.

The structure — three Base64URL parts joined by dots

A JWT is header.payload.signature, all Base64URL-encoded:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4iLCJpYXQiOjE1MTYyMzkwMjJ9.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded:

• Header: { "alg": "HS256", "typ": "JWT" } — algorithm and token type.
• Payload: { "sub": "1234", "name": "John", "iat": 1516239022 } — the claims.
• Signature: HMAC-SHA256 of base64url(header) + "." + base64url(payload) with the shared secret.

The payload is not encrypted. Anyone with the token can read its contents. The signature only proves the token has not been modified since it was issued.

Standard claims (RFC 7519) — what each one is for

Algorithm choices — pick deliberately

The fork in the road is symmetric vs asymmetric:

• HS* (symmetric) — same secret signs and verifies. Simpler, faster. Use only when one entity owns both ends.
• RS* / ES* / EdDSA (asymmetric) — private key signs, public key verifies. Required for any setup where the issuer and verifier are different services or where verifiers need to be untrusted (mobile clients, third-party APIs).

The classic JWT attacks — and how to defend

1. alg: none — the attacker resigns the token with alg: "none" and sends it. Vulnerable libraries skip signature verification because the spec technically allowed unsigned tokens. Defence: hard-code an allow-list of accepted algorithms; reject everything else, especially "none".
2. Algorithm confusion (RS → HS) — server is configured for RS256 but accepts any algorithm. Attacker takes the public key (which is, well, public) and uses it as the HMAC secret with HS256. The signature now verifies because the library treats the public key as a shared secret. Defence: tie the algorithm to the key type — never let HS algorithms verify with an RSA public key.
3. Key confusion via jku / jwk headers — attacker sets a header that points the server at an attacker-controlled JWKS URL. Defence: never trust jku / jwk / x5u / kid values from the token; resolve keys from a server-side allow-list.
4. Long-lived tokens — leaked tokens give permanent access if they never expire. Defence: short-lived access tokens (5–60 min) + refresh tokens.
5. Replay across services — token signed for service A is replayed against service B (which trusts the same issuer). Defence: enforce aud claim validation per service.
6. Information leakage — sensitive data in payload because "it's signed". JWTs are not encrypted. Defence: keep payload minimal; for confidential data, use JWE (encrypted JWT) or store server-side and reference by ID.

Token rotation — the production pattern

Long-lived JWTs are an operational liability. The pattern that scales:

1. Access token: short-lived JWT (5–15 minutes). Sent on every request. Stateless verification.
2. Refresh token: opaque random string (not a JWT). Long-lived (days to weeks). Stored server-side, can be revoked. Used to mint new access tokens.
3. Refresh-token rotation: each refresh issues a new refresh token; the old one is invalidated. Detects token theft when a stolen refresh token is used after the legitimate one.
4. Key rotation: sign new tokens with key 2; keep verifying old tokens with key 1 until they all expire. Use the kid header so verifiers know which key to use.

Verification in 6 languages — the safe way

const jwt = require('jsonwebtoken');
const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256'],   // explicit allow-list — defends against alg=none
  issuer: 'https://issuer.example.com',
  audience: 'my-service'
});

import jwt
decoded = jwt.decode(
  token, secret,
  algorithms=['HS256'],
  issuer='https://issuer.example.com',
  audience='my-service'
)

parser := jwt.NewParser(jwt.WithValidMethods([]string{"HS256"}))
token, err := parser.Parse(tokenStr, func(t *jwt.Token) (any, error) {
    return secret, nil
})

Algorithm alg = Algorithm.HMAC256(secret);
JWTVerifier verifier = JWT.require(alg)
    .withIssuer("https://issuer.example.com")
    .withAudience("my-service")
    .build();
DecodedJWT jwt = verifier.verify(token);

use jsonwebtoken::{decode, DecodingKey, Validation, Algorithm};
let mut v = Validation::new(Algorithm::HS256);
v.set_audience(&["my-service"]);
v.set_issuer(&["https://issuer.example.com"]);
let token = decode::<Claims>(token, &DecodingKey::from_secret(secret), &v)?;

use Firebase\JWT\JWT;
use Firebase\JWT\Key;
$decoded = JWT::decode($token, new Key($secret, 'HS256'));

JWE vs JWS — when you need encryption, not just signing

JWS (JSON Web Signature) is what most people mean when they say "JWT" — payload is signed but readable. JWE (JSON Web Encryption, RFC 7516) wraps the payload in encrypted form so it cannot be read without the key. Use JWE when:

• You need to put PII in the token (legal/GDPR concern).
• The token traverses untrusted intermediaries.
• You want server-to-server data passing without a database round-trip.

JWE has 5 parts (header.encrypted-key.iv.ciphertext.tag), is roughly 50% larger than JWS, and adds complexity. Default to JWS unless you have a specific reason for encryption.

Common JWT mistakes

• Storing JWT in localStorage. Vulnerable to XSS. Use httpOnly cookies for browser sessions; use Authorization headers for API clients.
• Skipping issuer/audience validation. Just calling jwt.verify(token, secret) without checking iss and aud opens cross-service replay.
• Putting passwords or full user objects in the payload. Sub claim + lookup is the standard. Never put sensitive material in JWTs unless using JWE.
• Forgetting clock skew. Servers' clocks drift; exp validation should allow ±30–60 seconds of leeway.
• Using HS256 with a 12-character secret. The minimum security level requires the secret to be at least as long as the hash output (256 bits = 32 random bytes for HS256).
• Hard-coding secrets in client code. Anyone with the secret can forge tokens. Secrets live in env vars on the server, never in the bundle.
• Treating JWT logout as "delete the cookie". A copy of the token may exist in a tab, in monitoring, in a logger. Real logout requires server-side token blacklist or short expiry + refresh rotation.