JSON Web Tokens are everywhere in modern authentication, and they are easy to get subtly wrong. Auditing a JWT setup is about confirming the token cannot be forged, cannot be replayed forever, and only carries what it should. Here is what to look at.
Never trust the token’s own algorithm blindly
The most famous JWT flaw is algorithm confusion. A token declares its own signing algorithm in the header, and a naive verifier will honor it. An attacker can switch a token to none, or trick a server that verifies with a public key into accepting a token signed with that public key as if it were a shared secret. Your verifier must pin the expected algorithm and reject anything else, rather than reading the algorithm from the untrusted token.
Validate expiry and the time-based claims
A token without a short expiry is a long-lived password. Check that exp is present and enforced, and consider nbf (not before) and iat (issued at) for extra safety. Short-lived access tokens paired with a revocable refresh mechanism limit the blast radius if a token leaks.
Check the audience and issuer
Confirm the token was issued by your authority (iss) and intended for your service (aud). Skipping these lets a token minted for one service be replayed against another that shares a key. Validate them explicitly.
Handle signing keys like the crown jewels
The signing key is the entire trust anchor. Keep it out of source control, rotate it, and use asymmetric keys (a private key to sign, a public key to verify) when different parties are involved so the verifier never holds signing power. Weak or hard-coded secrets turn the whole scheme into theatre.
Keep the payload minimal
A JWT payload is signed, not encrypted — anyone holding the token can read it. Never put passwords, full personal records, or secrets in the claims. Carry an identifier and the minimum authorization data, and look up the rest server-side.
What a healthy setup looks like
Pinned algorithm, enforced short expiry, validated issuer and audience, rotated asymmetric keys, and a lean payload. If your audit confirms all five, most JWT attacks simply have nothing to grab.
Audit tokens from applications you own or are authorized to assess. Decoding and testing tokens from systems you do not control may be unlawful.