JWT Decoder

A JWT is three Base64url segments joined by dots. The header names the signing algorithm in `alg` and often a key identifier in `kid`, which tells the verifier which public key to use. The payload holds the claims - who the token is about, when it expires, what it grants. The signature covers the first two segments and is what makes the token trustworthy.

The header and payload are encoded, not encrypted. Anyone holding the token can read every claim in it, which is why a JWT must never contain anything confidential. Putting a password, an internal database ID you would rather not expose, or personal data beyond what the client already knows into a JWT is the most common design mistake with the format.

The signature is the part that matters for security and it is unreadable by design - it is raw bytes, not text. Seeing gibberish in the third segment is correct.

This is the single most important thing to understand about JWTs. Decoding reads the claims. Verification checks the signature against a key and confirms the token has not been forged or altered. They are completely separate operations, and only one of them provides any security.

Anyone can take a valid token, change `"role": "user"` to `"role": "admin"`, re-encode it, and produce a token that decodes perfectly and displays exactly what they want. Nothing about the decoded output would reveal the tampering. Only signature verification catches it, and verification requires the secret or public key.

So a decoder is a debugging aid, not a security check. It is for looking at what a token claims while you work out why a request is being rejected. Verification belongs in your application, using a library, with the key held server-side. Never make an authorisation decision from decoded claims alone.

HS256 is symmetric: one secret both signs and verifies, so every verifying party can also mint tokens. That is fine within a single service and unacceptable across trust boundaries. RS256 and ES256 are asymmetric: a private key signs and a public key verifies, so you can distribute verification without distributing the ability to issue. For anything multi-party, including OIDC, asymmetric is the correct choice.

The `alg: none` vulnerability comes from libraries that honoured the header's own claim about which algorithm to use. A token declaring `none` with an empty signature was accepted as valid, because the library trusted the attacker-controlled header. Modern libraries reject `none`, but the lesson generalises: never let the token decide how it is verified. Pin the expected algorithm in your verification call.

The confusion attack is the subtler cousin. If a service verifies with RS256 but a library allows the algorithm to be chosen by the header, an attacker can submit an HS256 token signed with the public key as the HMAC secret - and since the public key is public, they can sign it themselves. Pinning the algorithm prevents both.

`exp` is the expiry as a Unix timestamp in seconds, and it is the most important one to validate. A common bug is passing milliseconds, which yields a date in the year 55,000 and a token that never expires. `iat` is when the token was issued and `nbf` is the earliest time it becomes valid.

`iss` and `aud` identify the issuer and the intended audience, and both should be validated. Skipping `aud` means a token issued for a different service in the same ecosystem will be accepted by yours - a genuine privilege escalation path in multi-service environments.

`sub` identifies the subject, and `jti` is a unique token identifier that supports revocation lists. Revocation is JWT's real weakness: a stateless token stays valid until it expires, so there is nothing to invalidate. The standard mitigations are short expiry with refresh tokens, or a server-side deny list keyed on `jti` - which reintroduces the state that JWTs were meant to avoid.