Auth0 Home Blog Docs

Caching JWKS signing key



This doc states:

Currently Auth0 only supports a single JWK for signing, however it is important to assume this endpoint could contain multiple JWKs. As an example, multiple keys can be found in the JWKS when rotating signing certificates.

  1. typically, when does a rotation of the signing certificates happen? who/what triggers it?

  2. when a rotation happen, are all new tokens signed with that new certificate or is there some kind of delay before being in use?

I am trying to avoid fetching the certificate when new tokens kid are submitted to my app, and instead have a separate process that will refresh a cache of active keys asynchronously. But for this to work I need to fetch the signing certificate before my app needs it. Any tips on how to do this would be greatly appreciated.



Hi @benji.

As of now, we don’t offer any customer-facing way to control or force the rotation of certificates. Nor is something that we currently do on a regular basis. This could very well change in the future. Imagine these possibilities:

  • Tenant admin triggers the rotation of the tenant certificate manually (maybe adding a new one in the list, and making in “active” at a later time).
  • A private key is compromised and a rotation is needed immediately.
  • Certificate rotation is scheduled to happen at a certain frequency.

An ideal strategy would probably cache the keys for a long time (forever?) and attempt to fetch new ones if a signature verification fails. The (very well thought out) ASP.Net Core OIDC stack does that (code in Github).


Hi @nicolas_sabena, thank you for your answer.

Note that I’m more interested in some form of notification (event) of the rotation of the keys rather than being able to control/force it.

With the current implementation of the core framework (and many other), an attacker spamming unrecognized signatures/KIDs will trigger as many outbound requests to refresh the certificate(s) every time. This is not ideal in terms of performance and cost.

Some frameworks have the options of rate limiting (like auth0’s node-jwks-rsa). But then if the attacker spams unrecognized signatures/KIDs and rate-lock the refreshing of the keys while a key is being compromised/rotated, then the keys won’t be refreshed for some time (by default up to 10 minutes). This means that valid tokens won’t be validated during that time frame. Depending on the app this can be more or less of an inconvenience.