Caching Differences between Development and Production Tenants

[habikki]

I have a development tenant that I’m using to build out what will be going to production and I’ve noticed something I wanted to clarify before running into the issue later.

I’ve noticed that GET /.well-known/openid-configuration off a custom domain is only cached for 15 seconds.

HTTP/2 200 
date: Mon, 15 Sep 2025 17:52:22 GMT
content-type: application/json; charset=utf-8
content-encoding: br
cf-ray: 97f9fa3b2be1e9e5-LAX
cf-cache-status: EXPIRED
access-control-allow-origin: *
cache-control: public, max-age=15, stale-while-revalidate=15, stale-if-error=86400
last-modified: Mon, 15 Sep 2025 17:52:22 GMT
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding, Origin, Accept-Encoding
access-control-allow-credentials: false
access-control-expose-headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After, DPoP-Nonce, WWW-Authenticate
x-auth0-l: 0.041
x-auth0-requestid: 7175fec565ed0872587f
x-cache-status: BYPASS
x-content-type-options: nosniff
x-ratelimit-limit: 300
x-ratelimit-remaining: 299
x-ratelimit-reset: 1757958803
server: cloudflare
alt-svc: h3=":443"; ma=86400
X-Firefox-Spdy: h2

In development this seems ideal as it:

1. States that caching is applied
2. Is low enough to expect rapid prototyping of changes to the OIDC configuration

Ideally this would be raised to something reasonable for production tagged tenants? I see no way this is configurable.

Thanks in advance for the confirmation.

Cheers,
Robby

[nik.baleca]

Hi @habikki

Welcome to the Auth0 Community!

Unfortunately, you are unable to configure the max_age of the cache since this is a standard practice by Auth0 and it is consistent across all tenants, regardless if they are a Development or Production one. This is an intentional part of the OIDC protocol which ensures your tenant’s security.

As a potential workaround, if this duration would not be suitable for your production environment, you can cache the JWKS locally for a longer period. If the keys are revoked, you can just make another request to the JWKS endpoint in order to retrieve the newest keys and re-attempt validation.

If you have any other questions, let me know!

Kind Regards,
Nik

[habikki]

Thanks for the reply @nik.baleca. You’ve confirmed that I can expect caching to remain consistent across tenantes which I had a suspicion on but wanted to plan for ahead of time.

Appreciate the information. I’ll ruminate with my team and plan for the short cache as best as we can.