JWT Decoder

JWTs in CTF web challenges

A JSON Web Token is a compact, URL-safe way to transmit claims between parties. It consists of three base64url-encoded parts separated by dots: header.payload.signature. The header specifies the signing algorithm (e.g. HS256), the payload carries the actual claims, and the signature verifies integrity.

Common CTF vulnerabilities involve JWTs:

• Weak secret - if the HMAC secret is short or guessable, forge a new token with elevated privileges.
• Algorithm confusion - changing alg from RS256 to HS256 and signing with the public key as the HMAC secret.
• None algorithm - some libraries accept "alg": "none" and skip signature verification entirely.

Challenges solved with this tool: picoCTF 2023 - Java Code Analysis!?!.

The header and payload parts of a JWT are just Base64url-encoded JSON - there is no encryption by default. This means the payload is readable by anyone who holds the token, even without the secret key. Sensitive claims like role, admin, or userId are fully visible. In CTF challenges, decoding the payload often reveals the exact field you need to modify to escalate privileges.

To forge a modified JWT in a CTF, you typically need to re-sign the tampered payload with the correct algorithm and secret. If the server uses the none algorithm vulnerability, you can simply remove the signature and change alg to none in the header. For HMAC-signed tokens with a guessable secret (e.g., secret or password), crack the secret with tools like jwt-cracker or hashcat mode 16500.

Standard JWT claims to look for in the payload include sub (subject/user ID), exp (expiration timestamp), and iat (issued-at timestamp). An expired token (where exp is in the past) may still be accepted by a misconfigured server - this is worth testing when the challenge involves session management. Use the Timestamp Converter to convert iat and exp values to human-readable dates.