Introduction: The "Shared Secret" Problem

The HMAC Limitation

Imagine a nightclub where every bouncer needs a copy of the master guest list to verify entry. If you have 50 bouncers and one of them loses their copy, anyone who finds it can forge their own guest list. This is exactly the problem with HMAC-SHA256 (HS256) — the most common algorithm in basic JWT implementations.

HS256 relies on a Shared Secret (a symmetric key — essentially a password) to both sign and verify tokens:

• Service A (Issuer): Uses the secret to create the signature.
• Service B (Verifier): Needs the exact same secret to verify the signature.

The Problem: If you have 50 microservices that need to verify tokens, you must distribute that sensitive secret to 50 different servers. If any one of them is compromised — a misconfigured S3 bucket, a leaked environment variable, a rogue employee — the attacker can forge tokens and impersonate any user in your system. The blast radius is total.

The Asymmetric Solution

Asymmetric cryptography solves this with a mathematically linked key pair:

• Private Key: Held only by the Issuer (your Authentication Service). Used to sign tokens. Never leaves the auth server.
• Public Key: Shared freely with everyone. Used to verify signatures. Cannot be used to forge tokens.

The math guarantees that a signature created with the private key can be verified with the public key, but you cannot reverse the process — knowing the public key tells you nothing useful about the private key.

Common algorithms for asymmetric JWTs:
- RS256: RSA signature with SHA-256. Widely supported, larger key sizes (2048-bit minimum).
- ES256: ECDSA with P-256 curve and SHA-256. Smaller keys, faster operations, increasingly preferred.

Service B can verify the token using the Public Key, but it cannot forge new tokens because it lacks the Private Key. But how does Service B get the Public Key safely and automatically? That is where JWKS comes in.