Skip to main content
The JSON Web Key Set (JWKS) is a set of keys containing the public keys used to verify any issued by the and signed using the RS256 signing algorithm. When creating applications and APIs in Auth0, two algorithms are supported for signing : RS256 and HS256. RS256 generates an asymmetric signature, which means a private key must be used to sign the JWT and a different public key must be used to verify the signature. Auth0 uses the JSON Web Key (JWK) specification to represent the cryptographic keys used for signing RS256 tokens. This specification defines two high-level data structures: JSON Web Key (JWK) and JSON Web Key Set (JWKS). Here are the definitions from the specification: Auth0 exposes a JWKS endpoint for each tenant, which is found at https://{yourDomain}/.well-known/jwks.json. This endpoint will contain the JWK used to verify all Auth0-issued JWTs for this tenant.
Currently, Auth0 signs with only one JWK at a time; 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 application signing keys.

​
Cache the JSON Web Key Set

We recommend that you cache the JWKS your application retrieves from the JWKS endpoint, as this will:
  • Avoid consuming your tenant’s rate limits with repeated requests.
  • Improve performance by avoiding a network request to the JWKS endpoint on every token validation.
  • Improve resiliency, so your application can continue validating tokens if the JWKS endpoint is briefly unavailable.
You can use a JWKS library or your framework’s middleware to handle caching, including refetching on an unknown kid and rate limiting refetches. For example, our Quickstarts use libraries that handle this for you. To avoid the development and maintenance burden, we recommend against implementing caching yourself. However, if your use case requires it, you can follow this guidance:
  • Cache the JWKS for 5-10 minutes to avoid fetching it on every request. Longer intervals further reduce requests and latency.
  • When you rotate signing keys, Auth0 signs new tokens with the new key. If you receive a token whose key ID (kid) is not in your cached JWKS, invalidate your cache and fetch the JWKS again to retrieve the new key. Refreshing on an unknown kid rather than the cache lifetime lets your application pick up rotated keys promptly. This way, a longer cache interval does not delay rotation.
  • Limit how often you refetch on a cache miss (for example, retry only once) so that a batch of tokens signed with unknown keys cannot trigger a flood of requests to the JWKS endpoint and consume your rate limits. Set your cache interval based on how quickly you need to stop accepting tokens signed with a manually revoked key.

​
Learn more