AzureAD
Id.Web should not use DefaultAzureCredential in production code
Description
As per https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/best-practices?tabs=aspdotnet#use-deterministic-credentials-in-production-environments, DefaultAzureCredential (DAC) should not be used in production scenarios. This is based on a PIR. Please read the public doc for to see the scenario where DAC breaks production.
Id.Web uses DAC in production code https://github.com/AzureAD/microsoft-identity-web/blob/9bd521186bf9b00a2af4fc920be8c7f87683a012/src/Microsoft.Identity.Web.Certificate/KeyVaultCertificateLoader.cs#L82
Expected behavior
Consider using https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-9.0 to determine if the app runs in DEV or in STAGING or PROD. Not sure about ASP.NET Classic. If not possible, we should let the app developer choose.
If production env, we could use only the SP auth (env credential, msi credential, workload cred, FICs). In "dev" scenarios we can continue to use DAC.
Would need an opinion on how to actually fix this @jmprieur @jennyf19 . If we can use the "environment" concept, I would argue that this is not a breaking change. https://learn.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-9.0
Otherwise, it could be a breaking change.
@bgavrilMS @jmprieur I don't want to hijack this issue, but feel it's related in the sense that adhering to the best practices is currently not possible, as there's no way to override the credential used by KeyVaultCertificateLoader.
Ideally a credential defined like this:
// credential may be of another type such as `ChainedTokenCredential` or `VisualStudioCredential`.
var credential = new DefaultAzureCredential(
new DefaultAzureCredentialOptions
{
// Options here
}
);
builder.Services.AddSingleton<TokenCredential>(credential);
And/or like this:
builder.Services.AddAzureClients(
(builder) =>
{
builder.AddCertificateClient(new Uri("https://kv-x289-ci-we-d-0201.vault.azure.net"));
builder.UseCredential(credential);
}
);
Would cause the KeyVaultCertificateLoader to use that credential.
At my workplace, we mostly work with developer laptops, where a VisualStudioCredential is used for authentication, as these developer laptops do not have a managed identity (which has a higher priority in AzureDefaultCredential). However, we also have some developers using an Azure Virtual Machine. These VMs have a system assigned managed identity. As a result on these VMs the application when run through Visual Studio authenticates using the VM's managed identity and thus fails to authenticate with the key vault as the VM's identity has not been set up to have key vault access (and we are not planning to add this access).
Instead, we'd love to simply configure usage of a VisualStudioCredential, but that turns out to not be possible with the current KeyVaultCertificateLoader implementation.
