← Back to All Guides
Security & Privacy • 9 min read • September 26, 2026

Deconstructing JSON Web Tokens (JWT): Header, Claims, Signature Verification & Common Security Flaws

An in-depth guide to RFC 7519, base64url encoding, asymmetric RS256 vs symmetric HS256 signatures, and client-side token debugging.

By ToolHero Application Security & Identity Engineering

The Dominance of Stateless Authentication

In traditional web architectures, user authentication relied on stateful session identifiers stored in centralized memory caches (like Redis or Memcached). Every incoming HTTP request required a network database lookup to resolve the user identity.

JSON Web Tokens (JWT), standardized under RFC 7519, eliminated session lookups by packaging identity claims and permissions directly into a cryptographically signed, tamper-evident digital credential.

┌────────────────────────────────────────────────────────┐
│                   JWT TOKEN STRUCTURE                  │
│                                                        │
│  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9                  │  <-- Header (Base64Url)
│  .                                                     │
│  eyJzdWIiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJpYXQiOjE2f│  <-- Payload (Base64Url)
│  .                                                     │
│  SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c           │  <-- Digital Signature
└────────────────────────────────────────────────────────┘

Anatomical Breakdown of a JWT

A JWT consists of three distinct components separated by periods (.):

1. The Header

Specifies the token metadata and the cryptographic signing algorithm:
{
  "alg": "HS256",
  "typ": "JWT"
}
Common algorithms include:
  • HS256 (HMAC SHA-256): A symmetric algorithm where both the auth server and verifying microservice share a single private secret.
  • RS256 (RSA Signature with SHA-256): An asymmetric algorithm where the auth server signs with a private RSA key and client microservices verify using the public key.
  • 2. The Payload (Claims)

    Contains statement declarations regarding the authenticated subject and token lifespan. Standardized registered claims include:
  • sub (Subject): Unique user ID or entity identifier.
  • iss (Issuer): Identity provider URL.
  • exp (Expiration Time): Unix epoch timestamp after which the token is invalid.
  • iat (Issued At): When the token was minted.
  • Custom claims: User roles, email addresses, and tenant scopes.
  • 3. The Cryptographic Signature

    Calculated over the combined base64url-encoded header and payload:
    \text{Signature} = \text{HMAC-SHA256}(\text{base64Url}(Header) + \text{"."} + \text{base64Url}(Payload), \text{ secret})

    Critical Security Vulnerabilities in JWT Implementations

    1. Base64Url Is NOT Encryption!

    One of the most frequent junior developer misconceptions is confusing encoding with encryption:
  • A JWT payload is merely Base64Url encoded. Anyone possessing the token can decode and read every claim in plaintext.
  • Rule: Never place unencrypted passwords, credit card numbers, or sensitive PII inside a JWT payload.
  • 2. The Alg="none" Bypass Exploit

    Early JWT libraries contained a critical flaw: if an attacker altered the header to {"alg": "none"} and stripped the signature, vulnerable verification middleware would accept the unsigned token as valid, allowing total privilege escalation to administrator roles.

    3. Asymmetric-to-Symmetric Key Confusion (RS256 \to HS256)

    If an authentication server expects RS256 but allows the incoming token header to dictate HS256, an attacker can use the server's publicly available RSA public key as the HMAC secret key to forge valid administrator tokens.

    Inspecting Tokens Safely Without Cloud Leaks

    When developers need to inspect JWT timestamps, scopes, or claims, pasting authorization tokens into cloud-hosted debuggers risks exposing active user sessions to third-party access logs.

    ToolHero's JWT Decoder parses and formats header parameters, payload claims, and human-readable expiration dates 100% locally in your browser. Tokens never touch an external network.

    Frequently Asked Questions

    Is a JWT payload encrypted?

    No. Standard JWTs (JWS) are signed, not encrypted. The payload is Base64Url-encoded and can be read by anyone. If data encryption is required, JSON Web Encryption (JWE) must be used.

    Can I decode expired JWTs on ToolHero?

    Yes! ToolHero decodes all header and claim values, calculating whether the token is currently active or expired based on the exp claim.

    Does ToolHero log decoded tokens or bearer credentials?

    Never. ToolHero runs completely client-side in your browser. No tokens, secrets, or payloads are transmitted across the internet.

    Put This Theory Into Practice

    Experience zero-upload, client-side processing with ToolHero suite of free online utilities.

    Explore All Free Tools →