Credentials are a vital part of an application registration when your application is used as a confidential client. You can add certificates and/or client secrets (a string, also known as passwordCredentials) as credentials to your confidential client app registration. Application credentials are used by the OAuth Client to authenticate to the authorization server. The secret is known only to the OAuth client and the authorization server.

Why did we remove the option for long-lived client secrets?

The portal option to select ‘Never Expire’ option for the Client Secret Expiry was removed in April 2021.

The change to remove the option in Azure portal to set long lived secrets was enforced after considering the following reasons:

• Client Secrets with long expiration lifetime pose a security risk. While they offer convenience of a never expiring credential, an exposure of such an unmonitored credential could go undetected and potentially be misused by a malicious actor.
• The option to pick a never expiring client secret was a label in UI over a client secret with an expiration of 99 years from the date of creation. While it provided the impression that credential was long lived, the expiration date was set to 99 years.
• The user experience for the client secrets was also inconsistent because the ‘Expires’ column represented a date with a ‘never’ label.
• A mixed representation makes the API response and UI inconsistent. Data returned via the API has an expiration date for client secrets and represent 99-year expiration as a date value.
• Use of one long lived secret by multiple apps, puts all the apps at risk if a client secret was leaked. Unless actively monitored, a developer may never be aware of another app in his/her tenant compromised as their app is never disrupted.
• Microsoft strongly recommends that all client secrets are rotated every six months to keep apps and processes safe. We have come across various scenarios where secrets have been stored in unsafe storage locations.

Why do existing long-lived secrets no longer show ‘never’ as expiration date?

For existing long-lived secrets, the UI now shows the precise expiration date (format: MM/DD/YYYY) instead of “Never” for better transparency. While the portal provided an option to select ‘Never’, the expiration of those never expiring secrets was set to 99 years from their creation date. Client secrets previously created with the value of “Never” were set to expire in 99 years from the creation date. The UI now shows the precise date (Ex. 01/02/2119) rather than the keyword “Never” for better transparency. It also makes the data consistent with the response from the Microsoft Graph application API. However, this should not affect the usage of those client secrets until the expiration date as expected. As a best practice, Microsoft strongly recommends customers to avoid using client secrets with long expiration timestamps in production environments.

What does Microsoft recommend for Client Secrets?

We strongly recommend that you use x509 certificates issued by Trusted Certificate Authority as the only credential type for getting tokens for your application. Monitor your production pipelines to ensure credentials of any kind are never committed into code repositories. If you are using Azure, we strongly recommend using Managed Identity, so the application credentials are automatically managed. Please refer to the managed identities documentation for more details.

If you must use Client Secrets, Microsoft recommends that you set a secret expiration value of six months. Please consider these other recommendations while working with application credentials. We also provide Credential Scanner, a static analysis tool that you can use to detect credentials (and other sensitive content) in your source code and build output.

The plan and vision for Client Secrets is for the API and portal experience to be uniform, which is to allow a maximum lifespan of two years. We will announce these changes via various channels such as Azure AD breaking changes and the Azure monthly roadmap. For now, if you would like a long-lived secret, you can use the Microsoft Graph API or the PowerShell cmdlet to set a secret with an expiration date greater than two years. We will remove this option to better secure all applications in Azure AD. At that point, all new secrets will be limited to a two year maximum expiration.

Resources

• application: addPassword – Microsoft Graph beta | Microsoft Docs
• New-AzureADApplicationPasswordCredential (AzureAD) | Microsoft Docs