JWKS Generator — Build a /.well-known/jwks.json Endpoint

What is JWKS Generator?

A JWKS (JSON Web Key Set) is the standard way an auth service publishes the public keys clients need to verify JWTs it has issued. It lives at a stable URL (typically `/.well-known/jwks.json`) and contains multiple keys with unique `kid`s so the issuer can rotate keys without breaking in-flight tokens. This tool assembles the JSON envelope for you, safely stripping private components if you accidentally paste a private key.

How to build a JWKS endpoint

1. 1Paste one or more public keys — PEM (`-----BEGIN PUBLIC KEY-----`) or JWK. You can also paste a private key; the tool strips the private components (d, p, q, dp, dq, qi) automatically.
2. 2Optionally set `use` (`sig` for signing, `enc` for encryption) and `alg` (RS256, ES256, PS256, etc.) — most JWKS clients ignore these but they help humans reading the endpoint.
3. 3`kid` (key ID) is auto-generated from the RFC 7638 JWK thumbprint — a stable SHA-256 hash of the key's core parameters. This makes `kid`s deterministic and reproducible across runs.
4. 4The right pane shows the assembled `{ "keys": [ ... ] }` document. Copy or download it.
5. 5Serve it at `https://your-domain.com/.well-known/jwks.json` with `Content-Type: application/jwk-set+json` and `Cache-Control: public, max-age=3600`.

Use Cases

Code Examples

{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "alg": "RS256",
      "kid": "b1c9e4-…-thumbprint",
      "n": "0vx7agoebGcQSuuPiLJXZptN…",
      "e": "AQAB"
    },
    {
      "kty": "EC",
      "use": "sig",
      "alg": "ES256",
      "kid": "a45f1d-…-thumbprint",
      "crv": "P-256",
      "x": "MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4",
      "y": "4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM"
    }
  ]
}

import { createRemoteJWKSet, jwtVerify } from "jose";

const JWKS = createRemoteJWKSet(new URL("https://issuer.example.com/.well-known/jwks.json"));
const { payload } = await jwtVerify(token, JWKS, { issuer: "https://issuer.example.com", audience: "my-api" });

import jwt
from jwt import PyJWKClient

jwks = PyJWKClient("https://issuer.example.com/.well-known/jwks.json")
key = jwks.get_signing_key_from_jwt(token).key
payload = jwt.decode(token, key, algorithms=["RS256"], audience="my-api")

Key Concepts

JWK Thumbprint (RFC 7638)

A deterministic SHA-256 hash of the key's canonical JSON representation — just the essential fields, in sorted order. Because it's derived from the key material, the same key always yields the same `kid`, which is exactly what you want for stable references.

kid (key ID)

A string that both the JWT header and JWKS entry share so verifiers know which key to use. Any unique string works, but RFC 7638 thumbprints are the recommended default — they're globally unique per-key and never collide accidentally.

use vs. alg

`use` is coarse: `sig` (signing) or `enc` (encryption). `alg` is specific: `RS256`, `ES256`, `PS256`, etc. Most verifiers care only about `kty` (RSA/EC) and the key material; `use` and `alg` are hints for humans and stricter clients.

Private components

An RSA private key has `d`, `p`, `q`, `dp`, `dq`, `qi` in addition to the public `n` and `e`. An EC private key has `d` in addition to `x` and `y`. Publishing any of these to a JWKS is catastrophic — it hands attackers the ability to forge tokens. This tool strips them automatically.

Tips & Best Practices

• ▸Serve JWKS with `Cache-Control: public, max-age=3600` (1 hour). Verifiers cache the response, so rotation propagates slowly — plan for at least a full max-age of overlap between old + new keys.
• ▸Always publish the JWKS at `https://your-domain/.well-known/jwks.json`. That's the convention every JWT library assumes; put it elsewhere and integrations become annoying.
• ▸Content-Type should be `application/jwk-set+json` (or plain `application/json` — most clients accept either).
• ▸Never mix private and public keys in a JWKS. If in doubt, run the endpoint output through this tool again — pasting a JWKS with private components will surface warnings.
• ▸For key rotation, generate the new key at least one `max-age + longest-token-TTL` before you start signing with it. That gives every cached JWKS a chance to refresh before your new tokens hit the wild.