32

Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?

Loc Dai Le
  • 1,661
  • 4
  • 35
  • 70
  • 1
    I think the error message hints that secrets should no longer be used but rather certificate credentials: `AADSTS7000222: The provided client secret keys are expired. Visit the Azure Portal to create new keys for your app, or consider using certificate credentials for added security` – Christopher Oezbek Nov 29 '21 at 15:03
  • There is a feedback request to allow for extension of expirations without having to reset the passwords. Please upvote it as it would be a nice way to solve the issue of having to go through all apps using a secret every few years: https://feedback.azure.com/d365community/idea/c9d2da85-8be2-ec11-a81b-6045bd7ac9f9 – INNVTV Nov 02 '22 at 22:31

9 Answers9

27

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
Daniel James Bryars
  • 4,429
  • 3
  • 39
  • 57
  • 2
    This is the right answer in my opinion. I would just point out that there is another parameter to give the secret a name: -CustomKeyIdentifier "clientSecret" – netadictos Aug 03 '21 at 11:17
  • 1
    Is the -Value used to give the client secret a value, which we then use to authenticate within Azure function applications (along with the app id)? – Jono Suave Aug 12 '21 at 16:03
  • This answer works very well because even if you have an expired secret you can create a new one with the same value by using the -Value parameter. – nurdyguy Jun 22 '23 at 20:16
8

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.

Gaurav Mantri
  • 128,066
  • 12
  • 206
  • 241
  • Thanks for verifying that. Can I read upcoming updates and changes for Azure anywhere? – Loc Dai Le Apr 13 '21 at 12:44
  • For Azure AD, please see this: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new – Gaurav Mantri Apr 13 '21 at 12:54
  • 4
    I foresee a lot of production disruptions in two years time. This could be the next form of "certificate has expired" class of problems :) – MartinH Apr 21 '21 at 18:20
  • @GauravMantri I cannot find any explanation for this change in the link you pasted here, neither any update for april 2021. – Thibault D. Apr 22 '21 at 11:26
  • Is there a way to create an alert for an upcoming expiration? I've been looking into policy to see if there is a way to track it. Anyway to at least remind folks that this needs to be addressed. – Nathan May 06 '21 at 12:02
  • 1
    @GauravMantri can you post a citation for your assertion that the expiration age for the client secret is a maximum of two years please? I can set it to more than 2 years using PS (see my answer below.) – Daniel James Bryars May 12 '21 at 14:40
  • 1
    @DanielJamesBryars ... I have pinged a member of Azure Identity team regarding this. They would be the best person to answer. – Gaurav Mantri May 12 '21 at 14:52
  • 2
    @GauravMantri have they answered? – Juri Nov 24 '21 at 13:31
4

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/

Dmitry Kompot
  • 170
  • 1
  • 8
  • Via Powershell New-AzureADApplicationPasswordCredential I can(should I?) specify 10 years – Michael Freidgeim Mar 16 '22 at 02:42
  • To access the Microsoft Graph, without a **Ticking-Time-Bomb-2-Year-Key** use: Tutorial: Access Microsoft Graph from a secured .NET app as the app (https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-access-microsoft-graph-as-app?tabs=azure-powershell) – Michael Washington Apr 20 '22 at 22:13
2

Looks like we got an official answer from Microsoft's team at Jun 08, 2021, according to this discussion: https://learn.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.

vieira42
  • 81
  • 1
  • 6
1

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://learn.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest

stef
  • 33
  • 5
  • 2
    The commands need to be used with caution. If you have configured multiple secrets in an application, it will all get deleted except the one whose secret you're mentioning in the `--password` parameter. – Vishwas M.R Oct 29 '21 at 09:56
  • 2
    Thanks for catching this, good point. In my case I only had one so didn't try with multiple. In any case with azure CLI commands is best to test before doing it production env. – stef Dec 01 '21 at 21:42
0

There is an Azure Active Directory feedback request to allow for extension of expirations without having to reset the passwords. Please upvote it as it would be a nice way to solve the issue of having to go through all apps using a Client Secret every few years.

Azure DevOps allows for this on your Personal Access Tokens (PAT). Would love for this to work the same way and allow for extensions in both the CLI as well as the portal:

https://feedback.azure.com/d365community/idea/c9d2da85-8be2-ec11-a81b-6045bd7ac9f9

INNVTV
  • 3,155
  • 7
  • 37
  • 71
0

From a security best practices standpoint, you should never, ever use an expiration that long. The longer the secret stays the same, the higher the risk of credential loss becomes. Use 3 month or better 1 month expiration, implement a secret lifecycle management process and when possible always use certificates, better managed identities to avoid service principals/app registrations completely.

itpropro
  • 160
  • 1
  • 7
-1

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 year. Sure everyone KNOWs 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, stress or simply human error

Well done Microsoft, i feel safer already..

Mario B
  • 2,102
  • 2
  • 29
  • 41
  • 1
    There is a feedback request to allow for extension of expirations without having to reset the passwords. Please upvote it as it would be a nice way to solve the issue of having to go through all apps using a secret every few years: https://feedback.azure.com/d365community/idea/c9d2da85-8be2-ec11-a81b-6045bd7ac9f9 – INNVTV Nov 02 '22 at 22:32
  • It's actually a security risk to have secrets that are valid that long. Especially with app registrations, which are heavily used for persistence in Entra ID tenants, it's best practice to have a maximum of 3, better 1 month secret expiration and a proper secret lifecycle management process in place. – itpropro Aug 03 '23 at 07:33
  • You are right - I#ts better to have a proper process for that. And if you do it would be ok to enforce some stricter rules. BUT: most companies just don't have that and will handle this (especially the exchange of the token) pretty clumsily. So yeah, in a world where everyone is a security expert or at least very mindful about those things: I understand that limitation. In the REAL WORLD (the world we live in) it just creates a Security Risk. People who might not be prepared for that have to fiddly around with configurations/credentials, etc. – Mario B Aug 07 '23 at 08:03
-2

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

https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-client-secret

user16751753
  • 1