Feature:
Support multiple client secret for better client secret rotation and usage
Description:
We would like to request for a new feature to allow multiple client secrets to be active at the same time for each client. Preferably, each client secret should have a name / description and set expiration for each secret.
This implementation is already existing in AzureAD.
Use-case:
One of our security requirement is to regularly rotate client secrets. The current implementation carries operational risk because the old client secret will no longer work immediately, but the gap of updating the secret will cause issue. Having multiple client secret with expiry ensures sufficient time to issue new client secret and update it.
This implementation also allows us to issue client secret to developers for local or troubleshooting use cases without compromising actual client secret used in deployed environments
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.
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.
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.
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.
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!
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.
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.
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.
