JWT Structure and Signing

Three base64url parts

A JWT (RFC 7519) in its common signed form (JWS) is header.payload.signature, each part base64url-encoded. The header names the algorithm (alg) and often a key ID (kid). The payload holds claims: registered ones such as iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued at) and nbf (not before), plus your own. The payload is encoded, not encrypted, so anyone holding the token can read it; never put secrets in it. HS256 uses one shared secret for signing and verifying, so every verifier could also mint tokens. RS256 (RSA) and ES256 (ECDSA P-256) use a private key to sign and a public key to verify, which suits many services verifying tokens from one issuer.

Self-contained, signed claims

JSON Web Tokens carry signed claims that a server can verify without a database lookup, which brings both convenience and pitfalls.

A decoded JWT

Illustrative values.

// header
{ "alg": "ES256", "typ": "JWT", "kid": "2026-09-key-1" }

// payload (claims)
{
  "iss": "https://auth.example.com",
  "sub": "user_8f3a",
  "aud": "https://api.example.com",
  "iat": 1790000000,
  "exp": 1790000600,
  "scope": "orders:read"
}

// signature = ECDSA-P256-SHA256(base64url(header) + "." + base64url(payload), privateKey)

A sealed, transparent envelope

A JWT is like a letter in a clear envelope with a wax seal. Everyone can read the letter; the seal only proves who sent it and that nobody changed it.

Quick check: Why might several microservices prefer RS256 or ES256 over HS256?

• They can verify with a public key without being able to mint tokens
• Asymmetric signatures make the payload encrypted
• HS256 tokens cannot carry an exp claim
• RS256 tokens never expire