JSON Web Tokens (JWT, RFC 7519) are the de facto standard for stateless microservice authorization, OAuth 2.0 bearer flows, and Single Sign-On (SSO). Yet junior and senior engineers alike routinely make fatal security assumptions about tokens—from storing plaintext secrets in claims to pasting production authorization headers into sketchy web formatters.
1. Anatomy of a JWT: Base64URL Encoding is NOT Encryption
A compact JWT consists of three distinct segments separated by periods (.):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
├─────────────── HEADER ─────────────┤├──────────────────── PAYLOAD ───────────────────┤├────────────────── SIGNATURE ─────────────────┤JSON.parse(atob(token.split('.')[1])). Never put credit card numbers, unhashed passwords, or confidential PII inside JWT claims.
2. The Infamous 'alg: none' and Key Confusion Attack Vectors
Two classic vulnerabilities frequently compromise backend JWT verification:
- The 'alg: none' Exploit: The JWT specification originally allowed unsigned tokens for debugging. Attackers modify the header to
{"alg": "none"}, change their user ID toadminin the payload, remove the signature block, and send the forged token. Vulnerable backend libraries happily accepted it without verifying! - Algorithm Confusion (RS256 vs HS256): In asymmetric verification (RS256), the server uses a private key to sign and publishes a public key for verification. An attacker switches the algorithm to HMAC symmetric (HS256) and signs a forged payload using the public key as the secret HMAC key. If the server doesn't enforce strict algorithm whitelisting, the signature validates!
3. Essential Claim Validation: exp, nbf, iss, and aud Invariants
Never rely solely on signature math; always enforce standard registered claims:
exp(Expiration Time): Enforce tight token lifetimes (15 to 30 minutes). Never issue 30-day access tokens.nbf(Not Before): Reject tokens presented before their validity timestamp.iss(Issuer): Verify that the token originated from your trusted authentication provider (e.g.https://auth.mycompany.com).aud(Audience): Ensure the token was intended for your specific API service, preventing token replay across unrelated internal microservices.
4. The Production Leak Trap: Why Public Online Debuggers Steal Credentials
When an API endpoint returns 401 Unauthorized, developers instinctively paste the bearer token into third-party online decoders. Many of these free web utilities log submitted tokens in plain text. A production bearer token grants full administrative access to your customer databases until it expires. Always inspect tokens offline in your local developer sandbox.
5. How to Inspect, Decode, and Verify JWTs Safely in Client Memory
A secure in-browser decoder splits the string, decodes the UTF-8 Base64URL byte streams, parses the JSON payload, checks the exp timestamp against local time, and evaluates signature integrity—100% offline with zero network requests.
Written by Qwertygen Team
Engineering & Editorial Team at Qwertygen. Passionate about client-side document processing, data privacy invariants, and high-performance browser tooling.
