Azure App Registration using Managed Identities instead of Client Secrets

Im using the Microsoft Identity Web package latest (2.6.2) in .NET Core 7.0 to secure my front end app, which in turn calls a down stream api (API Gateway)

In order to call the downstream API, we have to configure a client secret which is stored in the client's App Registration in Azure.

Currently the "ClientSecret" could be stored in either the apps local settings (during dev) or the secrets.json file. I understand others have chosen to store the secret in Azure Key Vault, or possibly using an X509 cert instead which can achieve longer expiry time.

I'm actually in the process of migrating away using from connections strings/keys to using Azure Managed Identities to connect with the different services, for the simple reason of eliminating the challenge in key rotation which in a production environment just adds more pain.

Question - Even if not currently available, is Azure planning to extend the use of Azure Managed Identities as an option to eliminate the use of client secrets and the laborious secret key rotation process in App Registrations? Using Azure vault is all well and good but it doesnt solve the challenge for keys that evetually expire and need to be rotated, the onyly added value I see is the emans to remove the secret from the apps'code...

I'm looking a solution like the example below (which may not currently exisit)

// Using DefaultAzureCredential() instead of a client secret
// ---------------------------------------------------------
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi(new DefaultAzureCredential()) 
    .AddMicrosoftGraph(builder.Configuration.GetSection("GraphBeta"))
    .AddInMemoryTokenCaches();

If this is never going to happen, then one other options might be fetching the clinet secret from Azure Key Vault, the secret itself would ideally need to have an expiry longer than the current maximum 2 years.

I'm not sure if its possible to extend the expiry of the secret, Azure used to allow this as I'm still using one during development that was set to expire 12/31/2299.

Nowadays we get the "computer says no" greeting

As you already mentioned, it's better to use client certificates that will be more secure and stay long compared to client secrets.

If still client secret is your use case, you can check below results that I reproduced in my environment:

I got the same error as below when I tried to create client secret with expiry date as 12/31/2299 like this:

Note that, creating client secrets with custom expiry time of more than 2 years from Azure Portal(UI) is removed and no longer supported but you can still create them via PowerShell, Graph API etc...

I ran below Graph API query to create client secret with expiry date as 12/31/2299 in Graph Explorer like this:

POST https://graph.microsoft.com/beta/applications/<appObjectID>/addPassword

{
    "passwordCredential": {
        "displayName": "secret",
        "endDateTime": "2299-12-31"
    }
}

Response:

When I checked the same in Portal, secret is created successfully with long expiry date as below:

To create client secret with long expiry from PowerShell, you can make use of below commands:

Connect-AzureAD
$startDate = Get-Date
$endDate = $startDate.AddYears(300)
New-AzureADApplicationPasswordCredential -ObjectId 05b72b0a-0345-42b4-8ea2-a909e3eacb0c -StartDate $startDate -EndDate $endDate -CustomKeyIdentifier pssecret

Response:

When I checked the same in Portal, another client secret created with long expiry time as below:

References:

Future plans of Microsoft with the maximum expiration of a client secret - Microsoft Q&A by James Tran