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, 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.
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?
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)
Does this product still has a Development team? Looks like the last release was June 6 2022. 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?
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.
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.
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.