The Complete Guide to JSON Web Tokens (JWT), Cryptographic Verification & Security
Understanding RFC 7519, Base64URL encoding, symmetric vs asymmetric signatures, and client-side privacy.
JSON Web Tokens (JWT, pronounced "jot") are an open, industry-standard method defined in RFC 7519 for securely transmitting information between two parties as a compact, self-contained JSON object. Because JWTs are digitally signed using either a symmetric shared secret (such as HMAC SHA-256) or a public/private key pair (such as RSA or ECDSA), the receiving server can verify that the claims within the token have not been tampered with or altered in transit.
Today, JWTs are the foundational backbone of modern web applications, powering OAuth 2.0 authorization flows, OpenID Connect (OIDC) identity federation, single sign-on (SSO) systems, and stateless API gateway authentication across microservices.
Anatomy of a JWT: Header, Payload & Signature
In its serialized form, a JSON Web Token consists of three distinct strings separated by periods (.):
Specifies the token type (usually "JWT") and the cryptographic signing algorithm being used, such as "HS256" (HMAC with SHA-256) or "RS256" (RSA Signature with SHA-256).
Contains the statements or "claims" about an entity (typically the authenticated user or service) and additional metadata. Claims are split into registered claims, public claims, and custom private claims.
Created by taking the encoded header, the encoded payload, a secret key (or private key), and running them through the algorithm specified in the header. The signature guarantees that the sender is who it claims to be and that the message wasn't modified along the way.
Standard RFC 7519 Registered Claims Explained
While JWT payloads can carry arbitrary JSON key-value pairs, RFC 7519 establishes a set of reserved claims designed to ensure interoperability across identity providers and API gateways:
exp(Expiration Time): Unix epoch timestamp (in seconds) identifying when the token expires. Servers must reject any token wherecurrent_time > exp. PrivaStash converts this value into human-friendly relative countdowns (e.g., Expires in 42 minutes).iat(Issued At): Identifies the exact second the token was generated by the authorization server. Essential for detecting token age and stale sessions.nbf(Not Before): Defines the earliest second the token becomes valid. Tokens presented prior tonbfare invalid.sub(Subject): The unique identifier of the principal (such as a database user UUID, customer ID, or machine account).iss(Issuer): Identifies the authorization server that minted the token (e.g.,https://auth.company.com).aud(Audience): Identifies the intended recipients or backend APIs permitted to accept the token.
Symmetric (HS256) vs Asymmetric (RS256 / ES256) Signatures
When designing JWT-based architectures, choosing the right cryptographic signing scheme is essential:
Symmetric Signing (HS256 / HS384 / HS512)
Uses a single shared secret known to both the token issuer and the verifying service. Computationally lightweight and fast.
Asymmetric Signing (RS256 / ES256 / Ed25519)
Uses a private key to sign the token and distributes a public key (via JWKS endpoints) for verification.
Security Compliance: Why In-Browser Verification Protects Production Tokens
In modern production applications, JWT payloads frequently contain confidential enterprise data: internal employee database IDs, user email addresses, tenant UUIDs, OAuth scopes, and privileged RBAC permission sets.
When developers paste production tokens into web tools that execute decoding or verification on remote servers, they risk:
- Transmitting active bearer tokens across external networks where they can be intercepted.
- Storing confidential authentication credentials in third-party server access logs or telemetry.
- Violating enterprise security policies, ISO 27001 controls, SOC 2 compliance, and European GDPR data protection laws.
PrivaStash eliminates this risk entirely: all parsing, Base64URL string decoding, and HMAC cryptographic signature verification are executed exclusively within your browser's sandboxed memory using the W3C standard Web Cryptography API (window.crypto.subtle). Not a single character of your token or secret ever leaves your device.
Comparison: PrivaStash In-Browser Debugger vs jwt.io vs CLI
| Feature | PrivaStash (In-Browser) | jwt.io | CLI Tools |
|---|---|---|---|
| Server Uploads | 0 Bytes (100% In-Browser Memory) | Sends tokens across the network to auth servers | Local (requires terminal & node/python) |
| Confidentiality & Compliance | Safe for production tokens (HIPAA / GDPR safe) | Risks leaking user IDs & tokens to third parties | Local |
| Client-Side Cryptography | Hardware-accelerated Web Crypto (crypto.subtle) | Proprietary remote / client mix | Node crypto / OpenSSL |
| Interactive Claim Inspector | Live expiration countdown & human dates | Raw JSON only | Manual timestamp conversion required |
| Cost & Account Requirement | 100% Free Forever • No Login | Free (sponsored by Okta/Auth0) | Free |