> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging.auth0-mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.

> A JSON Web Key set is a JSON object which represents a set of JSON Web Keys (a JSON object that represents a cryptographic key).

# JSON Web Key Sets

The JSON Web Key Set (JWKS) is a set of keys containing the public keys used to verify any <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=JSON+Web+Token+%28JWT%29">JSON Web Token (JWT)</Tooltip> issued by the <Tooltip tip="JSON Web Token (JWT): Standard ID Token format (and often Access Token format) used to represent claims securely between two parties." cta="View Glossary" href="/docs/glossary?term=Authorization+Server">Authorization Server</Tooltip> and signed using the RS256 [signing algorithm](/docs/get-started/applications/signing-algorithms).

When creating applications and APIs in Auth0, two algorithms are supported for signing <Tooltip tip="Authorization Server: Centralized server that contributes to defining the boundaries of a user’s access. For example, your authorization server can control the data, tasks, and features available to a user." cta="View Glossary" href="/docs/glossary?term=JWTs">JWTs</Tooltip>: **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](https://tools.ietf.org/html/rfc7517) 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:

| Item                        | Description                                                                                                                        |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **JSON Web Key (JWK)**      | A JSON object that represents a cryptographic key. The members of the object represent properties of the key, including its value. |
| **JSON Web Key Set (JWKS)** | A JSON object that represents a set of JWKs. The JSON object MUST have a `keys` member, which is an array of JWKs.                 |

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.

<Warning>
  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](/docs/get-started/tenant-settings/signing-keys/rotate-signing-keys).
</Warning>

## 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](/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy) 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](/docs/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](/docs/get-started/tenant-settings/signing-keys/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](/docs/get-started/tenant-settings/signing-keys/revoke-signing-keys).

## Learn more

* [Signing Keys](/docs/get-started/tenant-settings/signing-keys)
* [JSON Web Key Set Properties](/docs/secure/tokens/json-web-tokens/json-web-key-set-properties)
* [Locate JSON Web Key Sets](/docs/secure/tokens/json-web-tokens/locate-json-web-key-sets)
* [View Signing Certificates](/docs/get-started/tenant-settings/signing-keys/view-signing-certificates)