Why Decoding a JWT Is Not Verifying It (And How Security Bugs Slip Through)

In an algorithm confusion attack, an attacker takes your public key (which is publicly accessible), changes the token header from RS256 to HS256 , and signs the token using your public key string as an HMAC secret! If your backend verifier doesn't enforce the algorithm, it might treat the public key as raw HMAC bytes and validate the forged signature as legitimate. Always pass algorithms=["RS256"] explicitly on your verifier. Never allow the token header to dictate which cryptographic algorithm to execute. 5. Debugging Tokens Locally Without Leaking Secrets During local development and testing, you frequently need to inspect token payloads, check exp timestamps, and debug custom claims. Pasting real staging or production tokens into random web decoders is risky. If the site routes requests through a backend server that logs incoming payloads, active session tokens can end up in third-party cloud logs. If you need to inspect a token quickly in the browser without sending data across the network, you can use our in-browser tool: 👉 DevOmniTools JWT Decoder It runs 100% locally in your browser memory using client-side JavaScript. Zero backend uploads, zero server requests, and zero remote logging. Quick Architecture Checklist - Frontends decode tokens solely for UI rendering-never for authorization logic. - Backends verify the cryptographic signature on every single protected API route. - Never expose symmetric HMAC secrets inside client-side bundles or mobile binaries. - Always hard-pin the allowed algorithms ( RS256 orHS256 ) in your verification middleware. - Verify expiration ( exp ), issuer (iss ), and audience (aud ) alongside the signature. Top comments (0)