JWT Verification best practise
To use a jwks.json endpoint for JWT verification and seamless key rotation, follow this technical workflow.
We advise following best practise when leveraging JWT Verification. In doing so, this also allows us to rotate the KMS keys which in-turn helps us to increase the resilience of our SaaS platform (Active/active implementations etc.).
Where to download the Keyless jwks.json endpoint
jwks.json endpointThe Keyless endpoint for downloading the jwks.json is available at https://api.keyless.io/customers/keyless/.well-known/jwks.json
The Verification Process
Extract the Header: Parse the JWT header (unverified) to retrieve the
kid(Key ID) andalg(Algorithm) parameters.Lookup the Key: * Search the cached
jwks.jsonfor a key where thekidmatches the JWT header. Confirm theuseproperty issig(signature) and thealgmatches your expected security profile (e.g.,RS256).Construct Public Key: Convert the JWK components (for RSA: the
nmodulus andeexponent) into a PEM-formatted public key.Validate Signature: Use the reconstructed public key to verify the JWT's cryptographic signature and check standard claims (
exp,iat,iss).
Handling Key rotation
To prevent authentication failures when keys are rotated, implement the following logic in your validation logic:
Caching with Refresh: Maintain an in-memory cache of the JWKS. Set a standard TTL (e.g., 24 hours).
Lazy Refresh on
kidMismatch: If a JWT arrives with akidnot present in your current cache, perform an immediate, one-time fetch of thejwks.jsonto see if a new key has been published.Rate Limiting: Limit "on-demand" JWKS fetches (e.g., once every 5 minutes) to prevent a malicious actor from triggering a Denial of Service (DoS) by sending tokens with random
kidvalues.Graceful Overlap: Ensure your verification logic can handle multiple keys in the
keysarray simultaneously. During rotation, the provider will publish both the old and new keys; your system should trust any valid key currently present in the set.
Last updated
Was this helpful?