JWT inspector

What this is actually doing

A JWT has three parts separated by dots. The first two are base64url, which is encoding, not encryption. That means anybody holding the token can read every claim in it without any key at all. The third part is a signature, and the signature is the only part that proves anything: it says the token was issued by whoever holds the key, and that nobody has changed it since.

This distinction is the whole reason the tool exists. Plenty of online decoders show you the claims and put a green tick on the page, which teaches exactly the wrong lesson. Here, the signature is reported as unchecked until a key is supplied and the maths actually agrees.

The most useful thing a token can tell you in an audit is how long it lives. An access token should expire in minutes. A token with no exp claim at all is valid forever unless something else revokes it, and a token with a thirty day lifetime turns one leak into a month of access. The inspector dates every time claim and says which of those you are looking at.

The alg: none example is worth loading. It is an unsigned token claiming to be an admin, and it is one of the oldest JWT vulnerabilities there is. A verifier that honours the algorithm named in the header, rather than deciding for itself which algorithms it will accept, will happily take it. The same family of bug covers algorithm confusion, where an attacker signs with HS256 using a public key as the secret, and a verifier that does not pin its algorithm believes them.

Other utilities