JWT Decoding vs Verification: Safe Inspection

Readable claims are not proven claims

A common signed JWT has three base64url-encoded segments separated by dots: a header, a payload, and a signature. Anyone who possesses the token can decode the first two segments. That is useful for debugging structure, but it does not prove who created the token or whether the payload was changed.

The JustUtils JWT decoder deliberately performs inspection, not trust validation. Treat every displayed field—including sub, roles, email, issuer, and expiration—as attacker-controlled until a trusted verifier accepts the token.

Decoding and verification answer different questions

Why an altered payload still decodes cleanly

Base64url is an encoding, not encryption and not an integrity check. An attacker can decode a payload, change "role":"user" to "role":"admin", and encode it again. A decoder will display valid JSON. A correct verifier rejects it because the old signature no longer matches the modified header and payload.

header.payload.signature
       ^ readable data
                      ^ integrity evidence checked with a trusted key

Never authorize a request from decoded payload fields alone. Verification must happen in the trusted application boundary before claims influence permissions or data access.

A verifier needs policy, not only a key

1. Restrict algorithms. Configure an allowlist; do not accept whichever alg the token requests.
2. Select a trusted key. Resolve kid only within keys belonging to the expected issuer, and handle key rotation.
3. Verify the signature. Check the exact encoded header and payload bytes with the allowed algorithm.
4. Validate issuer and audience. A valid token for another service or tenant must not be accepted.
5. Validate time claims. Enforce exp and, where used, nbf with a small documented clock-skew allowance.
6. Apply application rules. Check token type, scopes, subject status, and revocation or session state where required.

A cryptographically correct signature proves that a holder of the signing key produced the signed bytes. It does not automatically make the token suitable for every API.

Use numeric dates with explicit units

JWT NumericDate values such as iat, nbf, and exp count seconds from the Unix epoch. JavaScript timestamps commonly use milliseconds. Confusing the two introduces a factor-of-1,000 error. For example, 1_800_000_000 seconds is a plausible future JWT time, while the same number interpreted as milliseconds points near the beginning of 1970.

Convert timestamps for human review, but compare numeric values in the verifier. Displayed local time zones should not change the underlying expiration instant.

Inspect tokens without leaking bearer credentials

• Use a synthetic or redacted token whenever the header and claim shape are enough.
• Do not paste a live production token into chat, tickets, analytics fields, or an unknown website.
• If a real token must be inspected, use a trusted local environment and expire or revoke it afterward.
• Remember that browser extensions, clipboard history, screen sharing, and downloaded logs can expose locally processed data.
• Never place tokens in URL query strings; URLs commonly enter browser history and server logs.

Debugging checklist

1. Count the segments and decode only enough to identify the expected issuer and algorithm.
2. Compare iss and aud with the verifier’s configured values—not with assumptions from the UI.
3. Convert exp and nbf as seconds and compare them with a reliable clock.
4. Verify through the same maintained library and configuration used in production.
5. Log a safe error category, not the raw token or its sensitive claims.

Sources

• RFC 7519: JSON Web Token — JWT structure, registered claims, and NumericDate semantics.
• OWASP JSON Web Token Cheat Sheet — implementation threats and defensive guidance.