JWT HS256 Secret Generator

JWT secrets done right

A JSON Web Token (RFC 7519, 2015) is a compact, URL-safe container made of three Base64url-encoded segments — header.payload.signature — separated by dots. The signature is what keeps the token unforgeable; everything before the second dot is plain JSON readable by anyone. The signing algorithm is declared in the header's alg field and falls into three families: HMAC (HS256, HS384, HS512 — symmetric, shared secret), RSA (RS256, RS384, RS512 — asymmetric key pair, PKCS#1 v1.5), and the elliptic-curve variants ECDSA (ES256/384/512) and EdDSA (Ed25519). HS256 is by far the most common because it is the fastest, the simplest and good enough when issuer and verifier are the same service.

For HMAC, RFC 7518 §3.2 requires the secret to be at least as long as the hash output: 256 bits (32 bytes) for HS256, 384 bits for HS384, 512 bits for HS512. Anything shorter is trivially attackable offline: tools like hashcat -m 16500 chew through millions of candidates per second on a single GPU. Generate the secret with a CSPRNG — crypto.randomBytes(32).toString('base64') in Node, secrets.token_urlsafe(32) in Python, openssl rand -base64 32 at the shell.

Common pitfalls

• Using a human password as the secret. "supersecret123" has a few dozen bits of entropy; dictionary attack finishes before lunch.
• Regenerating the secret on every deploy. Every existing token is instantly invalidated and the user has to log in again — usually not what you want.
• Embedding the secret in the frontend. If the client must verify tokens, switch to RS256/ES256 and ship only the public key. HMAC secrets belong on the server.
• Trusting decode() without verify(). A famous category of bugs in jsonwebtoken and clones: jwt.decode never checks the signature; only jwt.verify does.

Historical attacks worth knowing

Three classic vulnerabilities still find their way into audits. The alg=none attack: an attacker forges a token with header {"alg":"none"} and an empty signature; a misconfigured library accepts it. The key confusion attack: a server expects RS256 (public key); an attacker swaps the header to HS256 and signs the token using the public key as the HMAC secret — the same library then validates it because it just takes the configured key bytes and runs HMAC. The jku / x5u injection: the header points at an attacker-controlled URL that returns the attacker's public key. Mitigation in all cases: pin the algorithm whitelist on verify ({ algorithms: ['HS256'] }), never trust header-supplied URLs and never share keys between algorithms.

Rotation and revocation

For graceful rotation, serve multiple keys via a JWKS (/.well-known/jwks.json) with a kid (key id) per entry; sign with the newest kid but accept tokens signed with any non-expired key. Revocation is the famously weak spot: JWTs have no built-in revocation. Practical patterns are a server-side deny-list of jti values until expiry, short-lived access tokens (5–15 min) backed by longer refresh tokens, or rotating the signing key to invalidate everything in bulk.

FAQ

HS256 or RS256? HS256 when the same service signs and verifies (single backend, internal microservice with shared infra). RS256 when one party signs and many parties verify, when you do not want the verifier to be able to mint tokens, or when the public key needs to be exposed.

Do JWTs expire? Only when you set the exp claim. Verifiers must check exp (and ideally nbf and iat) on every request — a missing or unchecked exp means the token lives forever.

Can I revoke a JWT? Not natively. You need a deny-list, short TTLs plus refresh tokens, or a key rotation.

Which library should I use? In Node, jose is the modern choice; jsonwebtoken works but has had several CVEs around algorithm handling. In Python use PyJWT with an explicit algorithms= list; in Java, JJWT.

Is the key generated here transmitted anywhere? No. Generation runs in your browser via crypto.getRandomValues() and the bytes never leave the page.