JWT Generator

Choosing an algorithm

The first decision is symmetric or asymmetric, and it is really a question about who needs to verify.

The rule that matters more than the choice: whichever you pick, pin it on the verifying side. A server that reads the algorithm out of the token it is verifying is exploitable regardless of which algorithm it was supposed to be using. See the algorithm-confusion explainer.

Signing a JWT in code

Node.js (jsonwebtoken)

import jwt from 'jsonwebtoken';

const token = jwt.sign(
  { sub: '1234567890', name: 'Test User' },
  process.env.JWT_SECRET,          // never a literal
  { algorithm: 'HS256', expiresIn: '1h' }
);

Python (PyJWT)

import jwt, os, datetime

token = jwt.encode(
    {
        "sub": "1234567890",
        "name": "Test User",
        "exp": datetime.datetime.now(datetime.UTC) + datetime.timedelta(hours=1),
    },
    os.environ["JWT_SECRET"],
    algorithm="HS256",
)

Go (golang-jwt)

import (
    "os"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
    "sub": "1234567890",
    "exp": time.Now().Add(time.Hour).Unix(),
})

signed, err := token.SignedString([]byte(os.Getenv("JWT_SECRET")))

Java (jjwt)

import io.jsonwebtoken.Jwts;
import java.util.Date;

String token = Jwts.builder()
    .subject("1234567890")
    .expiration(new Date(System.currentTimeMillis() + 3_600_000))
    .signWith(key)   // a javax.crypto.SecretKey, not a String
    .compact();

Testing that your server rejects bad tokens

Verifying that the happy path works is the easy half. The half that actually protects you is proving the unhappy paths fail. Every one of these should be rejected, and each is one toggle away on this page:

• A tampered signature. Flip the toggle above. Your server must return 401, not 200. If it returns 200, it isn't verifying at all.
• An alg:none token. Behind the expander above. A 200 here is a critical vulnerability — anyone can mint a token for any user.
• An expired token. Set exp to a past timestamp. Confirm your server checks expiry, and confirm the clock skew you allow is small.
• A token with the wrong aud. A token minted for another service must not be accepted by yours, however impeccable its signature.
• A token signed by the wrong key. Generate a second key pair and sign with it. Rejection should be immediate.

Turn each of these into a test case in your suite. They are cheap to write and they catch the failures that matter.

A note on the secrets this page generates

The default HMAC secret is 256 bits from crypto.getRandomValues(), which is a cryptographically secure source. It is fine for testing. For a production secret, generate it where it will live — in your secret manager, or via openssl rand -base64 32 — and never let it pass through a browser, a chat message or a commit. The secret key generator page explains what a good HMAC secret needs to look like.

Common questions

The rest of the workbench