Caching JWKS signing key

JWT.io
2

Hi @benji.

(This response was updated on April 2021 to reflect signing keys rotation and updated guidance on caching).

Auth0 nows support signing key rotation initiated by tenant admins (see Signing Keys for details). A tenant’s JWKS resource will have the current key and the “next” key, so applications that prepare in advance for a key rotation.

The JWKS resource will return the same set of keys most of the time. Applications should cache these resources, but they also need to be prepared to handle signing key rotations:

  • Tenant admin triggers the rotation of the tenant certificate manually (adding a new one in the list, and making it “active” at a later time). This is a prepared event, applications will see the “next” key before it is used to sign tokens, and switching to the new key will be handled gracefully.

  • A private key is compromised and a rotation is needed immediately. Auth0 would rotate keys and notify affected customers.

An application would need to decide on a cache lifetime that strikes a good balance between performance and security, particularly for the emergency case where a private key is compromised. In addition to fetching a new JKWS every so often (e.g. 1 hour), you might want to:

  • Try to fetch new keys if you can’t find a kid referenced in a token in the cached JWKS
  • Put some protection to avoid trying to refresh the JWKS resource constantly (someone could try a DDOS attack by sending a token with a non-existing kid). E.g. “Wait at least 5 minutes before trying to get a new JWKS”.

As an example, Microsoft’s ConfigurationManager class for .Net Core 6 has a 12h cache lifetime by default, and sets 5 minutes as the minimum time span that must pass between attempts to refresh the JWKS:

3 Likes