Naminc notes · 6 min read
JWT decoding is not JWT verification
A JWT can look legitimate and still be forged. Reading its claims is useful for debugging; trusting them requires cryptographic verification.
The three-part structure
A compact JSON Web Token usually contains three dot-separated values:
base64url(header).base64url(payload).signature
The header describes details such as the signing algorithm. The payload contains claims. Both are Base64URL-encoded, which makes them readable but provides no secrecy. The signature is computed from the first two parts and a trusted key.
What decoding proves
Decoding proves only that the first two token parts can be interpreted as data. Anyone can create a header and payload containing an administrator role, a chosen user ID, or an expiration date far in the future.
This means decoded claims are useful for inspection, but they must be treated as untrusted input until verification succeeds.
What verification checks
Signature verification checks whether the signed token data matches a trusted secret or public key. A secure JWT library should also restrict acceptable algorithms. Applications should not simply accept whichever algorithm a token header requests.
Verification belongs on the trusted side of an application, usually the server or an API gateway. A browser tool can decode a token without receiving keys, but it cannot establish that the token is authentic.
Claims still need validation
A valid signature is necessary, but it is not the complete authorization decision. Depending on the system, verify these claims too:
exp: the token has not expired.nbf: the token is active yet.iss: the token came from the expected issuer.aud: the token was issued for this application or API.- Application claims: roles and scopes permit the requested action.
Clock skew may justify a small tolerance for time-based claims. Keep that allowance deliberate and bounded.