[Feature Request] Load multiple enabled versions of the same certificate for easy rollover for token decryption

[chintanr97]

Is your feature request related to a problem? Please describe. Today, rotation of token encryption/decryption certificates is very complex (in our case for first-party). This is because, if I am using the AKV to generate my certificates, I need to achieve following manual steps during rotation:

1. The API code will have 2 certificates for decryption: C1 and C2. Upon a fresh start it will only load the latest versions of these certificates (let's say v1 in both the cases).
2. The AAD portal can only use one certificate to encrypt. Therefore, C1.v1 will be uploaded to the portal and chosen for encryption.
3. Now, the AKV mails us for arrival of expiry date of C1.v1 certificate. We go ahead and upload C2.v1 (assuming it has enough time before its own expiry) set it as the encryption certificate in the AAD portal.
4. Now the AAD app will start encrypting tokens using C2.v1. But the API service will not fail because it already had the configuration to use C2's latest version. In the worst case, we may have to restart service once, if a new version of C2 was issued before uploading to the AAD portal.
5. At this point we validate that APIs are working correctly and that the token encryption happens through C2.v1.
6. Now, we come back to AKV and issue a new version of the certificate C1, updating it to v2. And restart app service manually to reload the C1 certificate with version v2.
7. Next we go to the AAD portal, upload the C1.v2 certificate and set it to be used for encryption.
8. An token issued after this will be encrypted by C1.v2 and the API service would also be decrypt it correctly.

Now, these involve lot of manual steps because of 2 reasons:

1. AAD does not support auto-rotation for token encryption certificates.
2. MSAL library - even though allows loading more than 1 decryption certificates, it is not guaranteed that it will keep using previous x versions for the certificate. This is needed because, let's say, I just generated new version of the encryption certificate in the AKV, and my app service restarted for some reason, then it would only fetch the latest version of the encryption certificate and scenarios will break until I alter the AAD to use the new version of the certificate for encryption.

Describe the solution you'd like IMO, the library should fetch the previous x versions of the certificates, which may be enabled and not expired and try decrypting the token using any one of those certificates. This will help a lot, in terms of simplifying the rotation process as follows: Even though I generate a new version of the encryption certificate when old one is close to expiry, and by chance if the app service has restarted, it may fetch both the valid versions of the certificate and decryption of token will work just fine. I can then safely upload the new version to the AAD and set it to be used for encryption.

This saves the burden of maintaining primary and secondary certificates and several manual steps in their time-to-time rotation.

Describe alternatives you've considered It would be good to understand the priority of visualizing this feature. Because alternate routes include:

1. Manual approach as described above.
2. Developing teams need to write middleware to fetch the required versions and instances of certificates and use code configuration to perform token decryption.

While the first option is primary reason for this feature ask, the second option requires teams to manage additional code and ensure the reliability of certificate management.

Please let me know your thoughts with respect to the points here or if I am missing something that can help our scenario.

[chintanr97]

Hi Team,

I wanted to check for any update on this. It would be really useful to have this feature as it will get us closer to what auto-rotation would look like. Any thoughts on this would be really useful.

Regards, Chintan Rajvir