# Support multiple client secret for better client secret rotation and usage

**URL:** <https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443>\
**Category:** Product Feedback\
**Tags:** feature-request\
**Created:** [June 2, 2022, 1:48am UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443 "2022-06-02T01:48:26Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![Per.Gardebrink](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/User_font_awesome.svg/768px-User_font_awesome.svg.png) [@Per.Gardebrink](https://community.auth0.com/u/Per.Gardebrink)\
**Post date:** [November 24, 2023, 8:47am UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/25 "2023-11-24T08:47:41Z")

</div>

Any news on this?

The private key JWT solution suggested in this thread cannot be used in most third party libraries as far as I know for using OpenId Connect (M2M clients you roll yourself can of course do it easily).

I’d be happy when Auth0 can provide a way to implement secret rotation without downtime, for example in this sample: [GitHub - auth0-samples/auth0-aspnetcore-mvc-samples: Auth0 Integration Samples for ASP.NET Core MVC Web Applications](https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples), as there’s no way to implement a fallback functionality, or private JWT key signing, in the OpenId Connect library used there. Supporting multiple secrets to be valid at the same time seems like a quite simple solution to this and would work for any OpenId Connect library…

I was to be honest very surprised when we started using Auth0 about two years ago that a good way to implement secret rotation wasn’t there from the start. And now that all this time has passed and it’s been brought up in various threads here it’s still not implemented. I assume there’s things in the Auth0 infrastructure that makes this functionality to be more complex to implement than it looks on the surface given the time that has passed, but I think you really should prioritize it high given all the downsides of forcing your customers (us) to keep the secrets static over time.

---

<div class="post-metadata">

**Author:** ![KongMy](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/kongmy/32/34533_2.png) [@KongMy](https://community.auth0.com/u/KongMy)\
**Post date:** [November 27, 2023, 3:25am UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/26 "2023-11-27T03:25:38Z")

</div>

Hi Auth0, this topic remain open on our radar - is this topic still in roadmap consideration and what is your feedback?

---

<div class="post-metadata">

**Author:** ![Per.Gardebrink](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/User_font_awesome.svg/768px-User_font_awesome.svg.png) [@Per.Gardebrink](https://community.auth0.com/u/Per.Gardebrink)\
**Post date:** [January 17, 2024, 12:25pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/27 "2024-01-17T12:25:44Z")

</div>

It is to be honest a bit weird that this item is deemed “roadmap candidate” and not already on the actual roadmap as being a core security feature to be able to rotate secrets without breaking the application (which most likely means that no-one is actually rotating secrets).

Has this status been changed and added to the roadmap yet?

---

<div class="post-metadata">

**Author:** ![michael.wolfrum](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/michael.wolfrum/32/27687_2.png) [@michael.wolfrum](https://community.auth0.com/u/michael.wolfrum)\
**Post date:** [February 9, 2024, 11:59am UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/28 "2024-02-09T11:59:19Z")

</div>

We have this on our roadmap as **Zero Downtime Rotation for client secret - EA** which is currently targeted for SEP 2025 (please don’t read this as an ETA)

---

<div class="post-metadata">

**Author:** ![Yann.Mathieu](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/yann.mathieu/32/61864_2.png) [@Yann.Mathieu](https://community.auth0.com/u/Yann.Mathieu)\
**Post date:** [April 9, 2024, 1:50pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/29 "2024-04-09T13:50:52Z")

</div>

Hi Michael,

Does this product still has a Development team? Looks like the last release was [June 6 2022](https://auth0.com/releases). The most requested feature is on a roadmap for Sep 2025. Is this product being abandoned to the profit of Okta which has release [every months](https://help.okta.com/en-us/content/topics/releasenotes/production.htm)?

---

<div class="post-metadata">

**Author:** ![dhempy](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dhempy/32/61074_2.png) [@dhempy](https://community.auth0.com/u/dhempy)\
**Post date:** [October 12, 2024, 3:39pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/30 "2024-10-12T15:39:01Z")

</div>

It is shocking that industry-leader Auth0 doesn’t support multiple certificates, or some other strategy for seamless certificate rotations.

Coordinating an after-hours or weekend phone call with each customer every year is expensive, annoying, and error prone. We had one last night that went sideways due to a simple copy-paste error. We had to roll back quickly and reschedule another (after hours) appointment with the customer to try again with the corrected certificate.

Supporting multiple certificates has the potential of easing all that scheduling/downtime pain, AND provide a safe proving ground for new certificates’ accuracy and validity.

---

<div class="post-metadata">

**Author:** ![sstewart-alterra](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/sstewart-alterra/32/54045_2.png) [@sstewart-alterra](https://community.auth0.com/u/sstewart-alterra)\
**Post date:** [August 12, 2025, 7:00pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/31 "2025-08-12T19:00:57Z")

</div>

**FYI:** When you rotate an application client secret in Auth0, **it does not immediately invalidate access tokens** generated using the previous secret. This behavior is not explicitly mentioned in the “Rotate Client Secrets” documentation article, but it’s useful to know.

In our case, our applications cache access tokens. This meant we could rotate the secret in Auth0, and then update our application configuration a few minutes later— **without downtime** —because the cached tokens remained valid until they naturally expired.

On the other hand, if an application client secret was actually compromised, it is important for an administrator to be aware that **existing tokens will remain valid until they expire**.

Regardless, please prioritize this feature. It would certainly make the token rotation process less risky than the race against time to update the secret in our apps.

---

<div class="post-metadata">

**Author:** ![tim.george](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/tim.george/32/60323_2.png) [@tim.george](https://community.auth0.com/u/tim.george)\
**Post date:** [August 13, 2025, 5:49pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/32 "2025-08-13T17:49:01Z")

</div>

We too have been looking for the ability to allow a credential to have more than one secret, primarily for a zero downtime rotation of secrets. In our case, the credentials are used by our customers and cannot control how they use the credentials or cache the tokens and the ‘destructive’ rotation of a secret to a new value will break their integrations to our system. (except, as mentioned in the previous post, when they still have a cached token) Even a cached token is not bulletproof, what if a application node recycles or a new node starts? There will be no cached token an the currently deployed credentials are now invalid unless they have a distributed cache. But how distributed is that cache? node? K8s Pod? Region? Country? Global?

Currently we are forced to tell the customer to create a 2nd credential, update their applications and then delete the previous credential (blue/green type approach). This is a lot of work for each customer. Having more than one concurrent secret would allow them to only have to update a single value and delete the extra secret when done and would be less burden on our Auth0 tenant of not having to manage double the number of credentials and ensuring consistent scopes selected by a customer when they (today) create an additional credential.

With the ability to have more than one credential, it would be nice to have the optional ability to set a secret to expire in some interval. (Admittedly, this might not be a popular opinion, which is why I say ‘optional’) An expiration could perform the house cleaning of secrets in a more automated way.

---

<div class="post-metadata">

**Author:** ![diepes](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/diepes/32/79837_2.png) [@diepes](https://community.auth0.com/u/diepes)\
**Post date:** [June 23, 2026, 10:21pm UTC](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443/33 "2026-06-23T22:21:40Z")

</div>

Is this still an auth0 issue to be concerned about ?

[Previous page](https://community.auth0.com/t/support-multiple-client-secret-for-better-client-secret-rotation-and-usage/84443.md?page=1)
