Read a token without handing it to anybody JOT

The first two parts are not encrypted, and never were

A JSON Web Token is three pieces of base64 with dots between them. The header and the payload are base64, not ciphertext: anybody holding the token can read every claim in it without a key, without a tool, and without your permission. That is by design. The signature exists to prove the claims were not altered, not to keep them private.

Which is exactly why pasting a live token into a decoding website is such a bad idea. The token is the credential. Whoever holds it is the account it was issued to, until it expires. Most of those sites are run by honest people, and every one of them is a single breach away from holding a pile of other people's live sessions, with the timestamps and source addresses to go with them. This does the same reading here, in the tab, with nowhere to send anything.

What actually goes wrong with tokens

• alg set to none. The token is asking the other end to skip verification entirely. A verifier that honours it accepts anything anyone writes.
• A symmetric algorithm where an asymmetric one belongs. The classic confusion attack: a token signed HS256 arrives at a server expecting RS256, and the server helpfully uses its public key as the HMAC secret. The public key is public, so the attacker can sign with it.
• An expiry already past, or a token not valid yet. Timestamps are turned into dates here, because a ten-digit number is not something anybody reads correctly by eye.
• No expiry at all. The token is good until somebody changes the key, which in practice means for ever.
• A kid or jku pointing outward. Both tell the verifier where to fetch the key. A verifier that follows them without restriction can be pointed at a key the attacker controls.
• Claims carrying more about a person than a session needs. Email addresses, names, roles, internal identifiers, all of it readable by anyone who intercepts the token or finds it in a log.

Checking the signature, and doing it safely

Reading a token tells you what it says. Verifying it tells you whether to believe it, and that needs the key: the shared secret for an HMAC algorithm, or the public key for RSA or ECDSA. Both can be pasted here and the verification runs in the browser with the browser's own cryptography.

That distinction matters more than it sounds. Pasting a token into a remote decoder is bad; pasting the signing secret into one is handing over the ability to mint tokens for every account on the system, for as long as the key lives. There is no version of that which is acceptable, and it is a thing people do daily because the box was there.

A token that fails verification here is a token the server would also reject, which is useful when you are debugging why something is being turned away. A token that passes is signed by whoever holds that key, which is a narrower statement than “this token is fine”: an expired token with a perfect signature is still expired.

For the layer underneath, DECODE unwraps whatever the token turns out to be wrapped in, and EPOCH works out what a bare timestamp means. For the transport it arrived over, CERTLENS reads the certificate.