Azure 应用程序注册客户端机密过期
Azure App registration Client secrets expiration
Microsoft 是否已将客户端机密的有效期更改为最长 2 年？不可能再select“从不”了？
Has Microsoft changed the expiration date for Client secrets to be max
2 years? It is not possible to select "Never" anymore?
没错。客户端密钥的新有效期最长为 2 年。
有人可以指出 link Microsoft 为何以及何时强制执行此操作吗？这不是真正的安全最佳实践，可能会对工作应用程序产生严重影响。
这不是一个可能被泄露的密码暴露前端。有些秘密仅在服务器后端使用，并且很复杂并且至少有 20 个字符长。如今，蛮力无法破解这些。
所以事实上，因为 Azure 上没有像证书那样的监控和警报，所以它在 2 年内成为 Azure 用户的噩梦。
我自己 运行 对此感兴趣。您可以使用超过 2 年的 Powershell 设置添加凭据。所以我猜这是一个 UI 限制。
$startDate = Get-Date
$endDate = $startDate.AddYears(98)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId b09d3e1b-417d-425c-be05-9e46943d7207 -StartDate $startDate -EndDate $endDate
客户端机密的有效期限制为两年（24 个月）或更短。您不能指定超过 24 个月的自定义生命周期。
Microsoft 建议您设置一个小于 12 个月的过期值
您可以通过 Azure 内置 CLI 设置日期。
在浏览器中打开 Azure CLI。然后下面这个命令。注意：如果您不传递密码，这将重置您现有的密码！结束日期是您想要的任何日期：
az ad sp credential reset --name {name of your AD app} --end-date 2035-03-04 --credential-description DescriptionHere
如果你想保留我需要的 App Secret，我已经创建并开始使用它，请确保传递现有密码。
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 是可选的，但如果你不通过它，它在 UI 上将是空白的，这不是很好。
更多信息：
https://docs.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest
根据这个讨论，我们似乎在 2021 年 6 月 8 日从微软团队得到了官方答复：https://docs.microsoft.com/en-us/answers/questions/422538/future-plans-of-microsoft-with-the-maximum-expirat.html
这是他们工程团队的最终答案：
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).
所以，我了解到，有一段时间，我可以使用 Daniel 建议的 PowerShell 方法。
但是，我们不能永远依赖它，因为如果微软的计划实现，'never' 选项迟早会完全消失。我希望在这种情况下不会。正如一些人所说，由于这个限制，我也预见到未来几年会出现过期问题。
自 2022 年 2 月起，不再可能：
https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/
不幸的是，它无法更改，甚至无法通过直接操作您的应用程序注册 清单（这就是您更改其 UI 不支持的大多数内容的方式） ).
太好了，现在您必须为自己设置一个提醒，以便及时更新该应用程序。如果你离开公司，你之后的人很有可能会忘记它，一天又一天地破坏你的申请..
非常不寻常，据说只有您的服务器知道客户端机密 - 强制您在 2 年后更改它（其中显然未被破坏）究竟如何更安全？现在你的 Azure-operators 必须告诉你的 devs/devops 新的 client-secret.. 那是一个 high-senitive 必须以某种方式转移的信息 - 完全没有必要的风险！
这让我想起了一些你需要每个月更改 PW 的公司。我认为在这个时间点很好理解，这实际上 降低了 你的安全，因为人们很懒惰，会找到各种变通办法，比如附加数字（最坏的情况：当月）给密码，整体上大大削弱了密码强度。
如果您必须每周为您的一位客户发送新的 client-secret，情况也是如此。你当然知道你应该使用安全通道（就目前而言），但这只会引发因懒惰或人为错误而产生的安全问题
干得好微软，我已经感觉更安全了..
Microsoft 是否已将客户端机密的有效期更改为最长 2 年？不可能再select“从不”了？
Has Microsoft changed the expiration date for Client secrets to be max 2 years? It is not possible to select "Never" anymore?
没错。客户端密钥的新有效期最长为 2 年。
有人可以指出 link Microsoft 为何以及何时强制执行此操作吗？这不是真正的安全最佳实践，可能会对工作应用程序产生严重影响。
这不是一个可能被泄露的密码暴露前端。有些秘密仅在服务器后端使用，并且很复杂并且至少有 20 个字符长。如今，蛮力无法破解这些。 所以事实上，因为 Azure 上没有像证书那样的监控和警报，所以它在 2 年内成为 Azure 用户的噩梦。
我自己 运行 对此感兴趣。您可以使用超过 2 年的 Powershell 设置添加凭据。所以我猜这是一个 UI 限制。
$startDate = Get-Date
$endDate = $startDate.AddYears(98)
$aadAppsecret01 = New-AzureADApplicationPasswordCredential -ObjectId b09d3e1b-417d-425c-be05-9e46943d7207 -StartDate $startDate -EndDate $endDate
客户端机密的有效期限制为两年（24 个月）或更短。您不能指定超过 24 个月的自定义生命周期。 Microsoft 建议您设置一个小于 12 个月的过期值
您可以通过 Azure 内置 CLI 设置日期。 在浏览器中打开 Azure CLI。然后下面这个命令。注意：如果您不传递密码，这将重置您现有的密码！结束日期是您想要的任何日期：
az ad sp credential reset --name {name of your AD app} --end-date 2035-03-04 --credential-description DescriptionHere
如果你想保留我需要的 App Secret，我已经创建并开始使用它，请确保传递现有密码。
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 是可选的，但如果你不通过它，它在 UI 上将是空白的，这不是很好。
更多信息： https://docs.microsoft.com/en-us/cli/azure/ad/app/credential?view=azure-cli-latest
根据这个讨论，我们似乎在 2021 年 6 月 8 日从微软团队得到了官方答复：https://docs.microsoft.com/en-us/answers/questions/422538/future-plans-of-microsoft-with-the-maximum-expirat.html
这是他们工程团队的最终答案：
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).
所以，我了解到，有一段时间，我可以使用 Daniel
自 2022 年 2 月起，不再可能： https://devblogs.microsoft.com/microsoft365dev/client-secret-expiration-now-limited-to-a-maximum-of-two-years/
不幸的是，它无法更改，甚至无法通过直接操作您的应用程序注册 清单（这就是您更改其 UI 不支持的大多数内容的方式） ).
太好了，现在您必须为自己设置一个提醒，以便及时更新该应用程序。如果你离开公司，你之后的人很有可能会忘记它，一天又一天地破坏你的申请..
非常不寻常，据说只有您的服务器知道客户端机密 - 强制您在 2 年后更改它（其中显然未被破坏）究竟如何更安全？现在你的 Azure-operators 必须告诉你的 devs/devops 新的 client-secret.. 那是一个 high-senitive 必须以某种方式转移的信息 - 完全没有必要的风险！
这让我想起了一些你需要每个月更改 PW 的公司。我认为在这个时间点很好理解，这实际上 降低了 你的安全，因为人们很懒惰，会找到各种变通办法，比如附加数字（最坏的情况：当月）给密码，整体上大大削弱了密码强度。
如果您必须每周为您的一位客户发送新的 client-secret，情况也是如此。你当然知道你应该使用安全通道（就目前而言），但这只会引发因懒惰或人为错误而产生的安全问题
干得好微软，我已经感觉更安全了..