I’d like to second this. The “workaround” detailed here requires the implementing client to be concerned with the validity or invalidity of the key, which is something that I never want to have to think about in application code. It seems to imply application-level dynamic key management, which not every company will have implemented, nor will have engineering time to implement.
2 Likes
Hello, I think it the same feature request that I made before: Rotate application secrets.
@dan.woda @konrad.sopala can they be merged?
Thanks
Feature:
Multiple Application Secrets.
Description:
As for the management of signing keys, it would be interesting to allow an application to have more than one secret at a time. Azure AD provides this functionality with the addition of a mandatory expiration.
I know that this feature request have been already made.
Use-case:
We are using Auth0 for machine to machine authentication. We need to rotate secrets for security purposes, but will not be able to guarantee the simultaneous update of all applications. We therefore require apps to have multiple secrets so that the old “expiring” credential can exist for a time period while apps update to the newer secret over time.
Hey there!
Thanks for creating this feedback card! Let’s see if it gets some traction from other community members as well!
Our company can really use this feature. We rotate secrets before a blue/green deployment. Green deploy is aware of the new secret. If Green fails its health check, Blue Gets rolled back. Blue is only aware of the old secret which is no longer valid. This causes immediate down time for us without user interaction.
1 Like
Thank you for advocating for that!
This is fundamentally a best practice for security.
Without rotation, you encourage the bad security practice (or anti-pattern) of never rotating a static credential. Static credentials are notoriously susceptible to leaks, hard-coding in source code, etc. One of the most appropriate and practical countermeasure is to rotate frequently! But, the way this is currently it forces downtime, and therefore incentivizes not rotating because at the end of the day you need to have a working, available product to make money.
On the security compliance side: customers that can’t follow their service-account credential rotation policy would be also be de-incentivized from purchasing Auth0.
5 Likes
The worst thing is that Okta provides this feature – and auth0 and Okta are from the same company. This can’t be rocket science to add and is a really important and compelling feature!
This would be really useful for the use case here, and also to support using “off the shelf” libraries for authentication (use case brought up in another
post Is it possible to have multiple app secrets? - #3 by dan.woda)
1 Like
Hey there everyone!
We’re reviewing those feedback cards on a monthly basis and I’m gonna advocate for it in the next month’s round. Will let you know once I have any updates on that front.
1 Like
This seems really useful from a security standpoint and also useful for maintaining zero-downtime. I was surprised something like this wasn’t available already.
Hello, @konrad.sopala same feature request here Support multiple client secret for better client secret rotation and usage
Can they be merged for gain places in the feature request rank? 
Regards,
Jérôme
Hey there!
We should have some kind of update on that front next week. Thank you!
1 Like
Hey there!
So that’s the update from our product team on that front.
This feature request makes full sense and it is in our radar of roadmap candidates.
The good news is that we already offer an alternative for app credentials rotation with zero downtime. Enterprise customers can use Private Key JWT, where requests are signed with a private key by the app and Auth0 validates that with the corresponding public key, as registered for the App. This feature is in Early Access and will be in GA by mid April.
I’m gonna mark it as a temporary solution but obviously that doesn’t stop here.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
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, 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.
Hi Auth0, this topic remain open on our radar - is this topic still in roadmap consideration and what is your feedback?