Encoding and security guides

JWT verification: signature, expiry, issuer and audience

Verify HS256 with the intended key and validate claims separately before making an authorization decision.

Nav Tools ·

Decode for inspection

A decoded header and payload can be inspected without a key. An attacker can also construct a readable payload with any claims.

Use synthetic tokens when investigating the format. Never accept a role or user identifier merely because it appears in decoded JSON.

header.payload.signature
Decoded claims are observations, not authorization.

Fix the algorithm and key

The application must allow only its intended algorithms and obtain keys from a trusted source. Do not let an untrusted header choose an arbitrary verification method.

Nav Tools verifies HS256 with the supplied shared secret. It does not provide RSA, ECDSA or OpenID Connect key discovery verification.

Check the claims separately

A valid signature says the token was authenticated with that key. You still need issuer, audience, expiration and not-before checks as the protocol requires.

JWT exp and nbf use NumericDate seconds, not JavaScript milliseconds. Agree on a small clock tolerance rather than ignoring time checks.

Test failures as well as success

Try a wrong secret, a modified payload, an expired token and a wrong audience in the target authentication library. Each must fail for the appropriate reason.

The site’s HS256 result covers the signature only. Keep complete claim validation and authorization policy in the service receiving the token.

References

← Encoding and security guides