Azure AD 应用程序注册中的 Client Secret 最长到期时间修改为 2 年
Posted Justin-Liu
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Azure AD 应用程序注册中的 Client Secret 最长到期时间修改为 2 年相关的知识,希望对你有一定的参考价值。
当我们的应用程序被用作机密客户端时,凭据是应用程序注册的重要组成部分。我们可以添加证书和/或客户端密钥 (字符串,也称为passwordCredentials) 作为机密客户端应用程序注册的凭据。OAuth Client 使用应用程序凭据对授权服务器进行身份验证。这个密钥只有 OAuth 客户端和授权服务器知道。
为什么要移除密钥的永不过期选项?
其实微软早在 2021 年 4 月就移除了 Azure AD 应用程序注册中永不过期 (Never Expire) 这一选项,这个决策主要基于以下原因:
- 长生命周期的客户端密钥存在安全风险。虽然它们提供了永远不会过期的凭据的便利,但这种不受监视的凭据的暴露可能不会被发现,并可能被恶意的参与者滥用。
- 选择永不过期的客户端密钥实际上自创建之日起,有效期为 99 年。虽然它给人的印象是证书寿命很长,但它的有效期被设定为 99 年。
- 客户端密钥的用户体验也不一致,因为 Expires 列表示的日期带有 Never 标签。
- 混合表示会导致 API 响应和 UI 不一致。通过 API 返回的数据有一个客户密钥的过期日期,并以日期值表示 99 年的过期日期。
- 多个应用使用同一个长期存在的密钥,如果客户端密钥被泄露,那么所有应用都将面临风险。除非被积极监控,否则开发者可能永远不会意识到他/她的租户中有另一个应用被入侵,因为他们的应用永远不会中断。
- 微软强烈建议,所有客户端密钥每六个月轮换一次,以保证应用程序和进程的安全。密钥被存储在不安全的存储地点的情况太多太多了。
为什么现有的永久密钥不再以 Never 作为过期日期?
对于现有的长期密钥,UI 现在可以显示精确的过期日期 (格式:MM/DD/YYYY) 而不是 Never,以提高透明度。虽然门户提供了一个选择 Never 的选项,但那些永不过期的密钥被设置为自创建之日起 99 年的期限。之前创建的值为 Never 的客户端密钥被设置为自创建日期起 99 年后过期。UI 现在显示精确的日期 (如 2119/01/02) 而不是关键字 Never,以提高透明度。它还使数据与来自 Microsoft Graph 应用程序的响应保持一致。但是,在预期的过期日期之前,这不会影响这些客户端密钥的使用。作为最佳实践,微软强烈建议客户在生产环境中避免使用带有长过期时间戳的客户端密钥。
微软对客户端密钥的建议是什么?
微软强烈建议您使用受信任证书颁发机构颁发的 x509 证书作为您的应用程序获取令牌的唯一凭证类型。监视您的生产管道,以确保任何类型的凭证都不会提交到代码存储库中。如果您正在使用 Azure,微软强烈建议使用托管认证 (Managed Identity),这样应用程序的凭证就会被自动管理。有关更多细节,请参阅托管认证文档。
如果您必须使用客户端密钥,微软建议您将机密过期时间设置为6个月。在处理申请凭证时,请考虑其他这些建议。微软还提供 Credential Scanner,这是一个静态分析工具,您可以使用它来检测源代码中的凭证 (和其他敏感内容) 并构建输出。
客户端密钥的计划和愿景是让 API 和门户体验保持一致,也就是允许最长的使用寿命为两年。微软将通过各种渠道宣布这些变化,如 Azure AD 突破性变化和 Azure 月度路线图。现在,如果您想要一个长期存在的密钥,您可以使用 Microsoft Graph API 或 PowerShell cmdlet 来设置一个有效期超过两年的密钥。我们将在之后删除这个选项,以更好地保护 Azure AD 中的所有应用程序。届时,所有新密钥将被限制在最长两年的期限内。
参考资源
application: addPassword – Microsoft Graph beta | Microsoft Docs
New-AzureADApplicationPasswordCredential (AzureAD) | Microsoft Docs
以上是关于Azure AD 应用程序注册中的 Client Secret 最长到期时间修改为 2 年的主要内容,如果未能解决你的问题,请参考以下文章
使用 Terraform 在 Azure AD 应用注册中的应用程序 ID URI 引发错误
旧版Azure AD应用程序注册中的“授予权限”按钮与新体验中的“授予管理员同意”有何不同?