'Azure App registration Client secrets expiration
Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?
Solution 1:[1]
I just ran into this myself. You can set add a credential using Powershell which is more than 2 years. So I'm guessing it's a UI limitation.
$startDate = Get-Date
$endDate = $startDate.AddYears(98)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId b09d3e1b-417d-425c-be05-9e46943d7207 -StartDate $startDate -EndDate $endDate
Solution 2:[2]
Could someone please indicates a link why and when this has been enforced by Microsoft? This is not really a security best practice and could have a serious impact on working applications.
This is not a password exposed front-end that could be leaked. There are secrets that are used only from servers back-end and are complex and at least 20 characters long. No way a brute force can break these nowadays. So in fact because there is no monitoring and alerting in place on Azure like for certificates, it's gone to be a nightmare for Azure users in 2 years.
Solution 3:[3]
Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?
That's correct. The new expiration age for the client secret can be 2 years maximum.
Solution 4:[4]
Looks like we got an official answer from Microsoft's team at Jun 08, 2021, according to this discussion: https://docs.microsoft.com/en-us/answers/questions/422538/future-plans-of-microsoft-with-the-maximum-expirat.html
This was the final answer from their engineering team:
There are plans to limit lifetimes of the secret administratively. However, there are no current timelines or ETAs of when this will happen. Removing the UX option to have never expiring secrets is a first step of that process (you can still create secrets that never expire with PowerShell, AZ CLI and Graph API).
So, I understood that, for a while, I can use PowerShell's method suggested by Daniel in the accepted answer above. However, we cannot rely on this forever because sooner or later the 'never' option may disappear completely if Microsoft's plans materialize. I hope it doesn't in this case. As some have said, I also foresee expiration problems in the coming years because of this limitation.
Solution 5:[5]
You can set the date through Azure Built in CLI. Open the Azure CLI in the browser. Then this command below. Note: If you don't pass a password, this will reset your existing password! The end-date is whatever you want it to be:
az ad sp credential reset --name {name of your AD app} --end-date 2035-03-04 --credential-description DescriptionHere
If you want to preserve the App Secret, which is what I needed, I already had created the secret and started using it, make sure to pass the existing password.
az ad sp credential reset --name {name of your AD app} --password {whatever password you want to keep} --end-date 2035-03-04 --credential-description AppAccess
--credential-description is optional but if you don't pass one it will be blank on the UI which is not nice.
Further info: https://docs.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest
Solution 6:[6]
As of February 2022 it isn't possible anymore: https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/
Solution 7:[7]
It can't be changed unfortunately, not even by manipulating your App registration manifest directly (that's how you change most things that are not supported with their UI).
Great, now you have to set a reminder for yourself to update that application in time. If you leave the company there is a good chance the people after you will forget it and break your application from one day to the next..
Very unusual, that client secret supposedly is only known to your server - how exactly does forcing you to change it after 2 years (in which is was evidently unbroken) ANY safer? Now your Azure-operators have to tell your devs/devops the NEW client-secret.. that is a high-senitive information that has to be transferred SOMEHOW - completely unnecessary risk!
That reminds me a bit of companies where you need to change your PW every month. I think at this point in time it is well understood that this actually lowers your security, because people are lazy and find all kinds of workarounds, like appending numbers (worst case: the current month) to the password, greatly weakening the password strength overall.
Same if you have to send a new client-secret for one of your clients every week. Sure you KNOW that you are supposed to use a safe channel (as far as that even exists), but this just invites security issues born out of lazyness or human error
Well done Microsoft, i feel safer already..
Solution 8:[8]
Client secret lifetime is limited to two years (24 months) or less. You can't specify a custom lifetime longer than 24 months. Microsoft recommends that you set an expiration value of less than 12 months
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Daniel James Bryars |
| Solution 2 | dainfo99 |
| Solution 3 | Gaurav Mantri |
| Solution 4 | vieira42 |
| Solution 5 | stef |
| Solution 6 | Dmitry Kompot |
| Solution 7 | |
| Solution 8 | user16751753 |