Key rotation/ multiple client secrets

[twenzel]

Since Microsoft changed the Azure App ClientSecret policy, the secrets expires after max 2 years.

It's possible to add mulitple secrets to the Azure App but this client library does not support a mechanims like key rotation.

Please implement a feature to store/configure multiple client secrets and the "correct" one will be retrieved to aquire a token.

[jmprieur]

@twenzel : this might be more a feature for Microsoft.Identity.Web (which already processes the certificates this way).
I learnt last week that there is also a policy to prevent the use of secrets (if tenant admins want). Therefore I think the future is in certificates; But we sill need to have a better story for the cert rotation too.

[sander1095]

@jmprieur could you link me to the documentation on using certs that auto rotate?

If i understand correctly I would use put them in a keyvault and my appsettings.json would reference it. My azure ad app would just have an empty list of secrets/certs then, right?

[bgavrilMS]

@sander1095 - cert support in Microsoft.Identity.Web (MIW) is described here https://github.com/AzureAD/microsoft-identity-web/wiki/Certificates#using-certificates-with-microsoftidentityweb

If you keep your cert in KeyVault, MIW will attempt to re-load the cert when it sees that the current cert has expired. KeyVault allows you to store multiple certificates under the same name.

So the way it would work end to end is:

• you configure M.I.W. with certificate named CERT from KeyVault
• you upload a cert RSA1 to KeyVault, under name CERT
• you configure the app in the app registration portal to use cert RSA1

App is now in production and works fine. When you are nearing the expiry for RSA1 you:

• you configure the app in the app reg portal to use cert RSA2 (as well as RSA1 - multiple certs are supported!)
• upload a cert RSA2 to KeyVault, under the name CERT

Now 2 things can happen:

A. if your app is restarted for some reason, it will pull RSA2 from KeyVault and use it, even if RSA1 is still valid.
B. if your app is not restarted and RSA1 expires, M.I.W. will catch the exception that comes from ESTS and will reload the certificate named CERT from KeyVault. It will pick RSA2.

[sander1095]

So if I understand correctly it will still require some effort and timing? It feels like a SSL scenario that often are forgotten to be refreshed.

I can not make this a "set it up once, never worry about it again" thing?

[jmprieur]

@sander1095 : can you please elaborate on the SSL scenario? I don't understand how MSAL could be involved?
With SendX5C, you can rotate the keys without having to change them in Azure AD.

[sander1095]

Sorry, that was a bad example. Ssl is not related to MSAL at all. Let me explain:

Currently I use a Client Secret which expires in 2023. I have to set up calendar events, alerts, notify other colleagues, etc.. so no one forgets to refresh this secret in 2023. This is whaf I compared SSL certs to; devs that dont have auto-refreshin SSL certs on their site often forget to refresh them and get invalid certs.

Letsencrypt made this a lot easier by allowing you to automate it.

Furthermore, Client Secrets are not recommended for prod scenario's.

So I want to use certs. But I would like to use a cert and never worry about it again, or as little as possible. So it should refresh automatically?
I would also like to use the keyvault to store the cert.

PS:

What is that Send5Xc you mentioned?

[bgavrilMS]

send5xc is a feature available only for some 1st Microsoft internal tenants by which the certificate is identified via it's CA chain instead of the thumbprint. It's better described here. Trust is based on Subject Name and Issuer instead of thumbprint. Unfortunately I am not aware if this feature will be made available for 3rd parties, because it's difficult to enforce that one and only one issuer is associated with a tenant.

Key Vault offers a auto-rotation - see https://docs.microsoft.com/en-us/azure/key-vault/certificates/tutorial-rotate-certificates#update-lifecycle-attributes-of-a-stored-certificate. This allows you to load a certificate from KV based on its name.

But you still have to manually / or via automation upload each cert to AAD, since AAD needs to know the thumbprint of a cert (x5t). I think more automation here is what you are looking for?

[sander1095]

I just got it to work, so I don't need further help. But I do have the following suggestions/findings:

• make it very clear in the docs that sendx5c is not usable for 3rd parties.
• I found it weird that most docs from docs.microsoft.com on the subject of azure ad auth are rather limited compared to the wiki of this repo. I believe that the docs site might need to reference more strongly to the existence of the repo, or move the wiki to the docs site so docs are in 1 place?
• when generating a certificate in the keyvault for azure ad auth, explain what settings should and should not be used and why. There are a lot of them!

Perhaps some code suggestions:

• instead of having to link my code to the keyvault's certificate and my azure ad auth app to the certificate, only needing to specify the keyvault + cert connection in my code would be nice! But I do not know if this is feasible.
• if that is silly, perhaps instead of requiring the user to upload a .cer of a certificate in the portal for azure ad auth (which i had to export from the keyvault), add a way to select the certificate from the keyvault directly, OR specify a .cer manually?
• It would also be nice to make the app continue running when the certificate refreshes near expiry if we just loosely link the cert? Instead of requiring manual action.

[bgavrilMS]

Great feedback, thanks @sander1095 . CC @jmprieur @henrik-me

[bgavrilMS]

Guidance (for both 1p and 3p) is to use Managed Identity as it provides cert-less auth.