Tech blog and developer tools
A JWT (JSON Web Token) secret is the cryptographic key used to sign and verify JSON Web Tokens. JWTs were introduced in RFC 7519, published in May 2015 by the IETF. The concept was created by Michael B. Jones, John Bradley, and Nat Sakimura to solve a specific problem: how to securely pass claims between two parties without needing a database lookup for every request.
The secret is critical because it is the only thing preventing someone from forging tokens. If your JWT secret is compromised, an attacker can create tokens with any claims they want, including admin access. This is why using a strong, randomly generated secret of at least 256 bits is essential.
Fun fact: JWTs are not encrypted by default. They are only signed. Anyone can decode a JWT and read its payload using a tool like jwt.io. The signature only guarantees that the token has not been tampered with. If you need to hide the payload contents, you should use JWE (JSON Web Encryption) instead.
A JWT has three Base64-encoded parts separated by dots: the header (algorithm info), the payload (claims like user ID and expiry), and the signature (created using the secret). This is why JWTs always look like "xxxxx.yyyyy.zzzzz".
HMAC (HS256) uses a single shared secret for both signing and verifying. RSA (RS256) uses a private key to sign and a public key to verify. RSA is preferred when the verifier should not be able to create new tokens.
The most common JWT vulnerability is using a weak or default secret. In 2018, researchers found that many apps used secrets like "secret", "password", or "123456". Tools like jwt-cracker can brute-force weak secrets in seconds.
JWTs enable stateless authentication: the server does not need to store session data. This makes them ideal for microservices and APIs where multiple servers need to validate tokens independently without sharing a session store.