A JSON Web Token often contains readable JSON, but readability is not authenticity. A decoder splits the compact token and decodes its base64url segments. Verification is a separate cryptographic and application-level decision.
What a decoder can establish
RFC 7519 defines JWT as a claims representation carried in a JWS or JWE structure. For the common three-segment signed form, an inspector can display the protected header and claims set. That is useful for diagnosing an unexpected issuer, audience, expiry time, or key identifier.
A decoder cannot prove that:
- The signature is valid.
- The algorithm is allowed by the application.
- The key belongs to the expected issuer.
- The token was issued for this API or client.
- The token is current, non-revoked, or safe to disclose.
Any user can construct a token whose payload says "role": "admin". Trust begins only after verification against a configured policy.
Verify the algorithm instead of accepting the header
RFC 8725 recommends that applications configure an allowlist of acceptable algorithms and reject every other algorithm. The token’s alg value is input, not policy. Keys should be bound to their intended algorithm so an RSA public key is never accidentally treated as an HMAC secret.
Use a maintained JOSE library rather than implementing signature verification with string operations. The library should reject the entire token if any required cryptographic step fails.
Validate claims for the current context
Signature verification alone is insufficient. Check at least:
iss: exact expected issuer.aud: this service or client is an intended audience.exp: token has not expired, allowing only a documented clock-skew window.nbf: token is not used before its valid time.- Token type or purpose: access token, ID token, session token, or another profile must not be interchangeable.
Validate claim types as well as values. A string where an array is expected should not be coerced silently.
Handle key lookup defensively
Headers such as kid, jku, and x5u can influence key lookup. RFC 8725 warns against trusting received claims and URLs. Do not fetch an arbitrary key URL supplied by a token; use issuer-specific allowlists, fixed discovery endpoints, network timeouts, response-size limits, and cache rules.
Inspection checklist
- Redact live credentials before sharing a token in tickets or chat.
- Decode locally when possible and label the result “unverified.”
- Confirm the token profile and expected issuer.
- Verify with an allowlisted algorithm and trusted key source.
- Validate audience, time claims, required claims, and explicit token type.
- Log only a safe fingerprint or selected non-sensitive claims.