Definition

A JSON Web Token (JWT) is a compact, self-contained token format standardized in RFC 7519 (2015) that represents a set of claims as a JSON object, digitally signed to ensure integrity and (optionally) encrypted to ensure confidentiality. A JWT consists of three Base64URL-encoded parts separated by dots: a header (specifying the signing algorithm), a payload (containing claims—key-value pairs about the subject, issuer, expiration, and custom data), and a signature (computed over the header and payload using a secret or public/private key pair).

JWTs are “self-contained” because the token itself carries all the information needed to verify its authenticity and determine the holder’s permissions—no server-side session lookup is required. The verifier checks the digital signature against the issuer’s public key, validates the expiration timestamp, and reads the claims directly from the payload.

Why It Matters

JWTs are the dominant authentication token format for modern web APIs. Auth0 processes over 4.5 billion login transactions per month, the majority resulting in JWT issuance. Okta, Firebase, AWS Cognito, and virtually every OAuth 2.0 and OpenID Connect implementation uses JWTs as the bearer token format.

The stateless property is architecturally significant: a server that verifies JWTs does not need to maintain a session store. Each request carries its own authentication proof. This aligns naturally with serverless and edge computing architectures where there is no persistent server to hold session state. A Cloudflare Worker that receives a JWT can verify it using only the issuer’s public key—no database query, no Redis lookup, no session table.

The tradeoff is revocation. Because the token is self-contained, the server cannot invalidate it before its expiration time without maintaining a revocation list—which reintroduces statefulness. This is why short-lived JWTs (15 minutes to 1 hour) combined with refresh token rotation have become the standard pattern: the token’s ephemerality substitutes for revocation infrastructure.

How It Works

A JWT authentication flow follows a standard pattern:

  1. Authentication: The client proves identity to the authorization server—via Sign-In with Ethereum, OAuth, or credentials. The server verifies the proof.

  2. Token issuance: The server creates a JWT containing claims: sub (subject, identifying the user), iss (issuer), exp (expiration timestamp), iat (issued-at timestamp), and any custom claims (roles, permissions, wallet hash).

  3. Signing: The server signs the JWT using HMAC-SHA256 (symmetric, shared secret) or RS256/ES256 (asymmetric, private key). The signature covers the header and payload, meaning any modification to either invalidates the token.

  4. Delivery: The JWT is returned to the client, typically as an httpOnly, Secure, SameSite cookie or in the Authorization header.

  5. Verification: On subsequent requests, the client includes the JWT. The server (or API gateway) verifies the signature, checks the expiration, validates the issuer, and extracts the claims. No database lookup is required.

  6. Expiration: When the JWT’s exp timestamp passes, the token is no longer valid. The client must re-authenticate to obtain a new token.

Stealth Cloud Relevance

Stealth Cloud uses JWTs as the session authentication mechanism for Ghost Chat, issued after successful Sign-In with Ethereum verification. The JWT is configured with specific privacy-preserving properties:

  • 1-hour TTL: Short expiration minimizes the window of exposure if a token is intercepted.
  • httpOnly, Secure, SameSite=Strict cookie: The token is inaccessible to JavaScript (preventing XSS exfiltration), transmitted only over TLS, and sent only to the issuing origin.
  • Hashed wallet address: The sub claim contains a SHA-256 hash of the wallet address, not the address itself. Even if the JWT is decoded (the payload is Base64-encoded, not encrypted), the wallet address cannot be recovered from the hash.
  • No PII claims: The JWT contains no email, no name, no IP address—only the wallet hash, expiration, and session metadata.

This design makes the JWT compatible with zero-persistence architecture: the token is stateless (no session store required), ephemeral (expires in 1 hour), and pseudonymous (the subject is a one-way hash).

The Stealth Cloud Perspective

A JWT is a self-destructing credential—a proof of identity that carries its own expiration date and requires nothing from the server except a public key. Stealth Cloud uses JWTs precisely because they require no session store, leave no server-side footprint, and become cryptographic waste the moment their TTL expires.