Developer Technical Deep-Dive
JSON Web Tokens (JWT): Anatomy, Signature Verification & Security Mechanics
JSON Web Tokens (RFC 7519) are a compact, URL-safe means of representing claims to be transferred between two parties in modern web architectures, OAuth 2.0, and OpenID Connect flows.
1. The Three Segments of a JSON Web Token
A standard JWT consists of three distinct Base64URL-encoded strings separated by period (.) delimiters:
Header (JOSE)
Declares token type (
typ: "JWT") and cryptographic signing algorithm (alg: "HS256", RS256, or ES256).Payload (Claims)
Contains identity statements: registered claims (
sub, iss, exp, iat), public claims, and custom private tenant claims.Signature
Computed over
base64Url(Header) + "." + base64Url(Payload) with a shared secret or private key to ensure tamper-proofing.2. Token Expiration (exp) & Time Claims Architecture
RFC 7519 defines precise numeric timestamp semantics based on Unix Epoch seconds (seconds elapsed since 1970-01-01T00:00:00Z UTC). Production authentication services evaluate three critical temporal claims:
exp(Expiration Time): Identifies the exact instant on or after which the JWT must not be accepted for processing.iat(Issued At): Records the creation timestamp to reject tokens generated before a user changed their master password.nbf(Not Before): Defines a future timestamp prior to which the token cannot be utilized.
3. Critical Security Considerations: Decoding vs Encryption
Important: Standard JWTs are signed, not encrypted. The Header and Payload are simply Base64URL-encoded JSON objects. Anyone possessing the token can decode and inspect its full contents. Never store sensitive credentials, plaintext passwords, credit card numbers, or personally identifiable medical information in an unencrypted JWT payload.
EarnovaJWT parses and decodes your token completely in volatile browser memory using native JavaScript TextDecoder and JSON parsing APIs. No tokens, secrets, or identity claims are logged, cached, or transmitted to any server.