Azure/azure-sdk-for-net Azure.Core

1.62.0 (2026-08-20)

Added experimental (SCME0002) AzureCredentialResolver.Default public static property so standalone callers can share the process-wide credential cache used by DI-resolved paths.
AzureCredentialResolver now resolves every ChainedTokenCredential Sources[] entry through the active resolver chain, so any registered CredentialResolver (built-in, broker, or third-party) can claim or override an entry. Entries are constructed as chained, so transient failures surface as CredentialUnavailableException and the chain falls through.

AzureCredentialResolver now resolves a top-level single source (e.g. CredentialSource: AzureCliCredential) to the concrete credential type (AzureCliCredential) rather than a DefaultAzureCredential wrapper. Construction is unchanged (it uses the same DefaultAzureCredentialFactory helpers) — only the returned type differs; callers using CredentialSettings.TokenProvider as a TokenCredential are unaffected.
AzureCredentialResolver no longer claims top-level BrokerCredential sections (canonical name or broker alias); they now require BrokerCredentialResolver from Azure.Identity.Broker 1.7.0+ (e.g. via AddBrokerCredentialResolver()). BrokerCredential entries nested inside a ChainedTokenCredential continue to resolve. Note: if BrokerCredentialResolver from Azure.Identity.Broker 1.7.0 is registered ahead of AzureCredentialResolver, a nested BrokerCredential entry is currently built as non-chained, so it may surface AuthenticationFailedException and abort the chain instead of falling through to the next entry. Without a broker resolver registered, the built-in chain path builds the broker entry as chained (correct fall-through). A future Azure.Identity.Broker release will make its resolver honor chained semantics for nested entries.