Support multiple client secret for better client secret rotation and usage

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

Hi @KongMy,

Welcome to the Auth0 Community and thank you for the detailed feature request!

1 Like

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? :wink:
Regards,
Jérôme

@Jerome.Piquet.AD

Thanks for pointing it out. I merged them!