Deep dive into JSON Web Tokens (RFC 7519). Learn header decoding, registered claims, symmetric HMAC vs asymmetric RSA signatures, and security best practices.
1. Anatomy of a JSON Web Token
A JSON Web Token (RFC 7519) is a compact, URL-safe mechanism for transmitting claims between client and server. A JWT consists of three Base64URL-encoded strings separated by periods: Header, Payload, and Signature. Use the JWT Security Hub to inspect claims, analyze expiration, and test signatures locally inside your browser memory.
2. Registered Claims, the jti Nonce & Claim Classification
RFC 7519 categorizes JWT claims into three distinct groups: Registered, Public, and Private claims.
• Registered Claims: Predefined, recommended metadata fields including:
- sub (Subject): Unique identifier for the authenticated user or entity.
- exp (Expiration Time): Unix timestamp beyond which the token is strictly invalid.
- nbf (Not Before Time): Timestamp before which the token must not be accepted.
- iat (Issued At): Timestamp marking when the token was created.
- iss (Issuer) and aud (Audience): Issuing authority and intended recipient domains.
- jti (JWT ID): A unique cryptographic nonce identifying this specific token instance. The jti claim is critical for single-use token flows, one-time password (OTP) verification, and maintaining a distributed server-side revocation blacklist to invalidate tokens before their expiration window.
• Public Claims: Collision-resistant claims defined in the IANA JSON Web Token Registry or namespaced with collision-resistant URIs.
• Private Claims: Custom claims created to share application-specific information between consenting parties (e.g. `roles`, `tenantId`, `permissions`).
3. How the Cryptographic Signature is Calculated
The signature prevents tampering and guarantees token authenticity. To construct the signature, the Base64URL-encoded header and Base64URL-encoded payload are concatenated with a period delimiter and hashed using the specified algorithm and a secret key:
Cryptographic signature calculation formulas (HS256 vs RS256)
When implementing or auditing JWTs, protect your application against key vulnerabilities:
1. The "None" Algorithm Exploit: Malicious actors modify the header to `"alg": "none"` to bypass signature verification if the backend library is improperly configured.
2. Weak HMAC Secrets: Symmetric HS256 secrets under 256 bits can be brute-forced offline using GPU hash crackers. Always use cryptographically secure random keys of at least 256 bits (32 bytes).
3. Storing Sensitive Secrets in Payloads: Base64URL encoding is NOT encryption. Anyone holding the token can decode and read the payload claims immediately.
5. Debugging Tokens Safely in the Browser
Always decode and inspect token claims locally. Avoid sending auth tokens containing production session IDs or email addresses over external third-party servers. Use the JWT Security Hub or Base64 Toolkit to parse headers and payloads securely inside local memory.
Key Takeaways
A JWT consists of Header (algorithm), Payload (claims), and Signature (tamper prevention).
The jti claim provides a unique token ID essential for replay protection and revocation blacklisting.
Base64URL encoding is not encryption; never store confidential passwords or API keys inside token payloads.
Always enforce signature verification on your API servers and reject tokens with mismatched algorithms.
Use zero-latency client-side decoders to inspect token claims and expiration dates securely.
PP
Written by Pradhumn PawarAuthor & Site Operator
Founder and engineer at Outlivo. Building privacy-first, client-side web tools, developer utilities, and technical guides. Published on 2026-08-19.