Remove Azure.Identity from Microsoft.Data.SqlClient.Extensions.Azure

[Arjan321]

With the release of Azure.Core 1.53.0 (released 2026-04-09) and Azure.Identity 1.21.0 (released 2026-04-10) all types in Azure.Identity have moved to Azure.Core, there is no need to reference Azure.Identity anymore

The Azure.Core reference should be updated to at least 1.53.0 (currently 1.50.0) and the Azure.Identity reference dropped.
See this migration guide

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Feature
Environment	N/A — this is a dependency update request, no environment details required
Area	Area\Engineering
Duplicates	Related (closed): #1108 (split Entra auth into Extensions.Azure)
Regression	Not indicated

Analysis

This is a dependency modernization request for the Microsoft.Data.SqlClient.Extensions.Azure package. Since Azure.Identity 1.21.0, all relevant types have been consolidated into Azure.Core 1.53.0, making the separate Azure.Identity dependency redundant. The current Azure.Core reference (1.50.0) and the Azure.Identity direct dependency in the Extensions.Azure package should be updated accordingly. This is a low-risk, P3 engineering task with no behavioral changes expected for end users.

Next Steps

• Update Azure.Core reference in Microsoft.Data.SqlClient.Extensions.Azure to >= 1.53.0 in Directory.Packages.props (or the relevant .csproj).
• Remove the direct Azure.Identity package reference from the Extensions.Azure project, as its types are now part of Azure.Core.
• Verify that all Entra authentication modes (ActiveDirectoryDefault, ActiveDirectoryManagedIdentity, etc.) still work correctly after the change.
• Assign to Copilot coding agent to investigate the current Azure.Identity and Azure.Core version pins in the Extensions.Azure package, apply the update following the Azure.Identity 1.21.0 migration guide, and run existing auth tests to confirm no regressions.

Note: This triage summary is auto-generated by an AI agent. The analysis and suggestions above have not been verified by a human maintainer. Please treat as preliminary guidance only.

Generated by SqlClient Issue Auto-Triage for issue #4448 · 29.4 AIC · ⌖ 6.43 AIC · ⊞ 8.4K · ◷

[ErikEJ]

@Arjan321 See this commet on my reverted PR with a potential "break" for consumers:

#4200 (comment)

[paulmedynski]

I will revisit this for 7.0.3 now that we have:

• Upper bounds for all sibling packages, and
• Aligned to identical versions for all sibling packages, and
• Release all sibling packages together.

We may still need to wait for 7.1 to avoid early SqlClient 7.0.x adopters pulling in the newer Azure 7.0.3 - I will discuss with my colleagues and report back.

[vejhe]

This has become a bit more urgent with recent changes in Azure.Core as the Extensions.Azure makes assumption on how DefaultAzureCredentials should be configured.

See Azure/azure-sdk-for-net#60650 and in particular Azure/azure-sdk-for-net#60650 (comment) for a temporary solution.

If one tries to stay up to date with Azure packages, SqlClient stops working.

Any chance the Azure auth provider could be augmented with a configure delegate to avoid such a tight coupling?

[cheenamalhotra]

Any chance the Azure auth provider could be augmented with a configure delegate to avoid such a tight coupling?

@vejhe You can register your own provider as well by implementing yourself and register the same using SqlAuthenticationProvider.SetProvider(SqlAuthenticationMethod.ActiveDirectory{AuthMode}, new {CustomerProviderClass}());.

Take a read at https://learn.microsoft.com/en-us/sql/connect/ado-net/sql/azure-active-directory-authentication?view=sql-server-ver17#support-for-a-custom-sql-authentication-provider for an example.

Since this is a breaking change for customers of 7.1.0, we won't be taking it in the current Stable release milestone, but will address this in the next major (8.0.0) milestone.