RFC 7638 — JWK Thumbprint

Spec: datatracker.ietf.org/doc/html/rfc7638Status: Full

RFC 7638 defines a deterministic way to derive a fingerprint from the public-key material in a JWK. The thumbprint is computed by:

1. Selecting only the required members for the key type (kty, plus the type-specific public parameters — e.g. e, n for RSA; crv, x, y for EC).
2. Serializing those members as JSON in lexicographic order with no whitespace.
3. Hashing the serialization with SHA-256.
4. Encoding the digest as base64url without padding.

Because the thumbprint depends only on the key material, two parties given the same public key will always derive the same value.

How AuthHero uses it

• kid for signing keys — when a new signing certificate is generated (via key rotation, tenant seed, or first-time setup), AuthHero sets the JWK kid to the RFC 7638 thumbprint of the public key. The same value is published in /.well-known/jwks.json and embedded in the kid header of every signed JWT.
• Stable across cert reissue — because the kid is derived from the key, reissuing a certificate that wraps the same public key produces the same kid. Clients caching the JWKS do not need to re-fetch.
• Self-verifying — any client can recompute the thumbprint from the published JWK and confirm it matches the kid.

Backwards compatibility

Signing keys created before RFC 7638 was adopted retain their original kid (a hex-encoded certificate serial number). The kid is stored on each key row, so existing tokens continue to verify against existing JWKS entries — only newly created keys use the thumbprint format. Operators who want every key to use the new format can rotate via POST /api/v2/keys/signing/rotate.

Related standards

• RFC 7517 — JSON Web Key (JWK) — defines the JWK structure and the kid parameter.
• RFC 7519 — JSON Web Token (JWT) — kid in the JWT header tells verifiers which JWKS entry to use.