How can DefaultAzureCredential pick up an updated client secret from Azure Key Vault?

Below is some background based on the current behavior:

• The client secret used for acquiring tokens is read when the DefaultAzureCredential (or more generally the credential chain you configure) is constructed. In other words, the client secret is loaded once as part of the credential’s initialization—not every time a token is requested.
• The method EnableTokenAcquisitionToCallDownstreamApi doesn’t itself load the secret; it registers the confidential client (which then uses the credential you configured) to perform token acquisition. That token acquisition uses the credential instance (here created by DefaultAzureCredential), and so if that instance was created early on, it “remembers” the original secret.
• In your situation the Azure Key Vault provider is set up with a reload interval (12 hours) so that configuration is updated. However, if you’re still using a single instance of DefaultAzureCredential it will continue to use the initial client secret even if the configuration has been updated underneath.

In practice, if you need the client secret to be reloaded before the lifetime of the running application ends, you have these options:

1. Create a new instance of the credential (for example, by registering one as a scoped service rather than a singleton). This makes the credential fresh and picked up from configuration changes when a new request comes in. Note that doing so means you are not reusing the same instance for every call, but the in‑memory token cache (configured through AddInMemoryTokenCaches) typically operates on the token responses rather than on the underlying credentials. In many cases you still benefit from token caching because once you acquire a token using a new credential instance, that token can be cached until it expires.
2. Alternatively, if you can control the timing of secret rotation and how your credentials are constructed, then you may want to recreate or refresh the credential instance in response to configuration changes.

So to answer your questions directly:

• The client secret is loaded by the DefaultAzureCredential when it is instantiated rather than when EnableTokenAcquisitionToCallDownstreamApi is executed.
• If you require that the updated secret be used (for example, after it has been rotated in Key Vault), you would need to create a new DefaultAzureCredential instance (for example, by constructing it within a scoped service). This does not completely negate the benefits of token caching, because the AddInMemoryTokenCaches extension caches the actual access tokens. They are still reused until close to expiration, regardless of whether the credential instance is new per API request.

A simplified example might look like this:

CSHARPCopied
// Register the DefaultAzureCredential as scoped (or have a factory)
services.AddScoped<DefaultAzureCredential>(sp =>
{
    // When the service is created per request, it reads the latest config.
    return new DefaultAzureCredential(
        new DefaultAzureCredentialOptions { ExcludeSharedTokenCacheCredential = true }
    );
});

// Register the Microsoft Identity Web components as normal.
// They internally use the credential (or confidential client) that is configured.
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(configuration, "AzureAd")
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

This way, if you need the client secret to be updated on reload, the credential can be re-created as needed—while the token cache remains effective during each credential’s valid lifetime.

Remember, the choice depends on your scenario. If you rotate your client secrets periodically, and you wish to pick up the new secret without restarting the application, then constructing your credential instance more frequently (or having a strategy to refresh it) is the way to go.