Deep Dive: JSON Web Token Architecture, Cryptographic Guarantees, and Threat Vectors
Understanding the anatomy of RFC 7519, Base64URL serialization, and avoiding common authentication vulnerabilities.
Anatomy of a Three-Part JWT
A JSON Web Token consists of three distinct segments delimited by periods (.): the Header, the Payload, and the Signature. Contrary to common misconception, standard JWTs are signed, not encrypted.
Each segment is encoded using RFC 4648 Base64URL encoding, replacing standard URL-unsafe characters (+ and /) with hyphen (-) and underscore (_), while omitting trailing padding characters (=).
RFC 7519 Registered Claims Lifecycle
The JWT specification designates seven registered claim keys designed to orchestrate token lifecycle and authorization scope across distributed microservices:
- iss (Issuer): The identity provider (IdP) that generated the token.
- sub (Subject): Principal ID of the authenticated user or machine identity.
- aud (Audience): Recipient service or API URI intended to consume the token.
- exp (Expiration Time): UNIX timestamp after which the token must be rejected.
- iat (Issued At): UNIX timestamp indicating generation time.
Frequently Asked Questions
Is it secure to paste production JWTs or API bearer tokens into this inspector?
Yes, because this inspector operates completely in-browser using the native Web Crypto API and Base64URL decoders. No network requests are made, no tokens are transmitted over TLS to remote servers, and no persistence (localStorage or cookies) is touched. You can verify this by viewing your browser's DevTools Network panel.
How does the token expiration countdown work?
The inspector extracts the 'exp' (Expiration Time) claim from the JWT payload segment, converts the UNIX epoch seconds to a local JavaScript Date object, and runs a 1-second interval timer calculating the remaining seconds or elapsed time since expiration.
What is the 'alg: none' vulnerability in JWT implementations?
The 'alg: none' vulnerability (CVE-2015-9235) occurred in insecure backend JWT libraries that accepted unsigned tokens where the algorithm was set to 'none'. Attackers could tamper with the payload (e.g., escalating role to 'admin') and strip the signature, and the vulnerable server would accept it. Modern libraries explicitly ban the 'none' algorithm unless explicitly opted-in for unsecured test fixtures.
Why should JWTs not be stored in browser localStorage for sensitive SaaS apps?
Tokens stored in localStorage are accessible to any JavaScript running on the domain, making them vulnerable to Cross-Site Scripting (XSS) extraction. Best practice for sensitive session tokens is to store them in HttpOnly, Secure, SameSite=Strict cookies that cannot be read via document.cookie.