JWKS EC Generator (P-256/P-384/P-521)

JWKS with Elliptic-Curve keys

JWKS stands for JSON Web Key Set — a JSON document containing one or more public keys used to verify JWT signatures. It is defined by RFC 7517 (JWK) and RFC 7518 (JWA, the algorithms), and it has become the de-facto distribution format for public keys in OAuth 2.0, OpenID Connect, mobile auth and Kubernetes ServiceAccount tokens.

Anatomy of an EC JWK

An Elliptic-Curve JWK carries the public point of an EC key. The curve is identified by the crv field — typically P-256 (secp256r1), P-384 or P-521 — and the coordinates x and y are base64url-encoded big-endian integers.

{
  "kty": "EC",
  "crv": "P-256",
  "kid": "key-2026-01",
  "use": "sig",
  "alg": "ES256",
  "x": "base64url-x-coord",
  "y": "base64url-y-coord"
}

Required: kty, crv, x, y. Optional but recommended: kid (key id for rotation), use (sig or enc), alg (the JWA algorithm) and optionally x5c for X.509 certificate chains.

The JWKS endpoint

A JWKS is just a JSON object with a keys array, typically served at /.well-known/jwks.json. Clients fetch it once, cache it by Cache-Control: max-age=3600, find the right key by matching the JWT header's kid against the JWKS, and verify the signature.

ECDSA algorithms

• ES256 — ECDSA over P-256 with SHA-256. The most widely supported choice and the default for OIDC.
• ES384 — ECDSA over P-384 with SHA-384. Higher security margin, larger signatures.
• ES512 — ECDSA over P-521 with SHA-512 (note: 521-bit curve, 512-bit hash).
• EdDSA — Ed25519, RFC 8037. Even faster and smaller, but less universally supported.

EC versus RSA

Elliptic-curve keys are dramatically smaller for the same security level: a 256-bit EC key matches a 3072-bit RSA key. Signing is faster, signatures are shorter (~64 bytes for ES256 vs ~384 bytes for RS256), and JWT payloads stay slim. For new systems, EC is the modern default; RSA is mostly kept for legacy interoperability.

Key rotation in practice

Rotation is the whole reason JWKS publishes a set instead of a single key. The typical flow: generate a new key with a fresh kid, publish both old and new in the JWKS, sign new JWTs with the new key, wait for the old JWTs to expire, then drop the old key. Rotate at least quarterly, more often if you suspect compromise. Keep the private key on hardware (HSM, KMS, TPM) whenever possible.

Where you'll see this in production

Auth0, Okta, AWS Cognito, Google Sign-In, Apple Sign In, Microsoft Entra, Firebase Auth — every major identity provider publishes a JWKS endpoint. Kubernetes ServiceAccount projected tokens are verified against a cluster JWKS. Mobile and IoT auth flows rely on JWKS for offline verification.

FAQ

EC or RSA — which should I pick? EC is the modern choice: faster signing, smaller keys and signatures, equivalent security. Pick RSA only if you must integrate with old systems that don't support ES256.

Is kid mandatory? Not by the RFC, but strongly recommended — it is how clients pick the right key during rotation. JWKS with a single, immutable key won't scale.

How often should clients refresh the JWKS? Honour the Cache-Control header, but also refresh on demand whenever a JWT references an unknown kid. A common pattern is "cache 1 hour, force-refresh on miss".

Can I include the private key in the JWKS? Never — JWKS is meant for public keys. Keep private keys in a secret manager, an HSM or a KMS, and only the corresponding public key goes into /.well-known/jwks.json.