JSON Web Tokens (JWT): Claims, Cryptographic Signatures & Security Reference
Understand header, payload, and signature segments, standard RFC 7519 claims, and common security vulnerabilities.
Table of Contents
The Three JWT Segments
A JWT is composed of three Base64URL-encoded strings separated by dots: `header.payload.signature`.
| Segment | Example Decoded Content | Cryptographic Purpose |
|---|---|---|
| 1. Header | `{"alg":"HS256","typ":"JWT"}` | Specifies token type and the cryptographic signing algorithm. |
| 2. Payload | `{"sub":"123","role":"admin","exp":1730000000}` | Contains user session claims and authorization attributes. |
| 3. Signature | `HMACSHA256(base64Url(header) + "." + base64Url(payload), secret)` | Guarantees the token was not tampered with in transit. |
Standard Registered Claims (RFC 7519)
Reserved claim keys recommended for standard interoperability.
| Claim Key | Full Name | Type | Description |
|---|---|---|---|
| `iss` | Issuer | String | Identifies the principal that issued the token (e.g. `https://auth.example.com`). |
| `sub` | Subject | String | Identifies the user or client ID that the token represents. |
| `aud` | Audience | String/Array | Identifies the intended recipient services for this token. |
| `exp` | Expiration Time | Unix Timestamp | Mandatory expiration epoch time after which token MUST NOT be accepted. |
| `nbf` | Not Before | Unix Timestamp | Token must not be accepted prior to this timestamp. |
| `iat` | Issued At | Unix Timestamp | Timestamp recording exact second token was generated. |
Critical JWT Security Checklist
Rules to prevent critical authentication bypass vulnerabilities.
| Vulnerability | Attack Vector | Mandatory Mitigation |
|---|---|---|
| The "None" Algorithm Attack | Attacker sets `"alg": "none"` in header to bypass signature verification entirely. | Strictly reject any token where `alg` is none, whitespace, or missing. |
| HMAC vs RSA Key Confusion | Attacker signs token with server's public key using symmetric HS256 instead of RS256. | Hard-code expected verification algorithm on server; do not read algorithm from token header. |
| Sensitive Data in Payload | Storing passwords, PII, or internal secrets in payload. | JWTs are only signed, NOT encrypted! Anyone can decode Base64 strings. |
Interactive Client-Side Tools for this Guide
Test and run these patterns directly inside your browser with zero server uploads:
Private Online JWT Debugger & Token Inspector
Safely inspect and decode JSON Web Tokens with zero cloud transmission. Verify expiration countdowns, claims, and HMAC signatures in complete privacy.
Online Hash Generator (MD5, SHA-256, SHA-512)
Compute message digests and cryptographic checksums using native Web Crypto API. 100% private and client-side.
Webhook HMAC Signature Generator & Verifier
Cryptographically sign and verify incoming webhook payloads with your secret key. Supports Stripe, GitHub, and Shopify standards with zero server uploads.
Frequently Asked Questions
Are JWT tokens encrypted?
No! Standard JWTs (JWS) are digitally SIGNED, not encrypted. The header and payload are simply Base64URL-encoded JSON. Anyone who intercepts the token can read the claims.
How can I decode and inspect a JWT without exposing it to third-party servers?
Use DocSwift's in-browser JWT Debugger. It parses header, claims, and expiration timestamps locally in your browser memory with zero network uploads.