DefaultAzureCredentials无法通过Visual Studio认证：缺失tokenProvider.json

Let's break down the solutions to get your DefaultAzureCredential working properly for local debugging, since you've already confirmed ClientSecretCredential works but want to use the intended developer flow.

Core Fixes to Try #

1. Fix IIS Application Pool Identity & Profile Settings #

The root path issue happens because your IIS app pool is using the system profile instead of your developer user profile (where Visual Studio stores its auth tokens). Here's how to fix it:

• Open IIS Manager, navigate to your app's application pool.
• Right-click → Advanced Settings:
  • Set Load User Profile to True (this forces the app pool to load your user's profile instead of the system profile).
  • Change Identity from the default ApplicationPoolIdentity to your local developer user account (the same one you use to log into Visual Studio and Azure).
• Restart the application pool and your website.

2. Refresh Visual Studio Azure Authentication Credentials #

Even without a "re-authenticate" button in VS options, you can force a credential refresh:

• Close all instances of Visual Studio 2022.
• Open Windows Credential Manager (Control Panel → User Accounts → Credential Manager → Windows Credentials).
• Delete all entries starting with VS_ that relate to Azure.
• Reopen VS, sign back into your Azure account, and try debugging again.

3. Upgrade Azure.Identity & Key Vault Packages #

Your current package versions (Azure.Identity v1.8.0, Azure.Security.KeyVault.Secrets v4.4.0) have known compatibility issues with Visual Studio 2022's auth flow. Upgrade them to:

• Azure.Identity v1.10.0 or later (this fixes VS2022 token path resolution bugs)
• Azure.Security.KeyVault.Secrets v4.5.0 or later (matches the updated identity package)

4. Tweak DefaultAzureCredential Configuration for Local Debugging #

Since managed identity doesn't work locally, you can simplify the config to avoid unnecessary failed attempts:

_client = new SecretClient(new Uri(options.KeyVaultUri), new DefaultAzureCredential(
    new DefaultAzureCredentialOptions
    {
        ExcludeManagedIdentityCredential = true, // Skip local managed identity (not available)
        ExcludeVisualStudioCredential = false,
        ExcludeInteractiveBrowserCredential = true,
        ExcludeAzurePowerShellCredential = true,
        ExcludeAzureCliCredential = true,
        ExcludeEnvironmentCredential = true,
        ExcludeVisualStudioCodeCredential = true,
        ExcludeSharedTokenCacheCredential = true,
        // Remove ManagedIdentityClientId for local debugging (only needed in cloud)
    }
));

Why This Happens #

When using the default IIS ApplicationPoolIdentity, the app runs under the system account (C:\WINDOWS\system32\config\systemprofile), but Visual Studio stores its auth tokens in your personal user folder (C:\Users\[YourUsername]\AppData\Local\.IdentityService\AzureServiceAuth). By switching the app pool to your user account and enabling profile loading, the app can access the correct token file path.

Old Azure.Identity versions also had hardcoded path logic that didn't account for VS2022's auth setup, which upgrading fixes.

Validation Steps #

1. First test your app directly in Visual Studio (without IIS) to confirm the Visual Studio credential flow works on its own.
2. If that works, switch back to IIS debugging and verify the path error is gone.
3. For deeper debugging, enable verbose Azure.Identity logging by adding this to your App.config:

   <system.diagnostics>
       <sources>
           <source name="Azure.Identity" switchName="Azure.Identity">
               <listeners>
                   <add name="console" />
                   <add name="file" />
               </listeners>
           </source>
       </sources>
       <switches>
           <add name="Azure.Identity" value="Verbose" />
       </switches>
       <sharedListeners>
           <add name="console" type="System.Diagnostics.ConsoleTraceListener" />
           <add name="file" type="System.Diagnostics.TextWriterTraceListener" initializeData="azure_identity_logs.txt" />
       </sharedListeners>
   </system.diagnostics>
   

   The log file will show exactly which credential flows are being attempted and where failures occur.

内容的提问来源于stack exchange，提问作者cognophile