Visitar URL original
Remove dependencies to Microsoft.IdentityModel from main SqlClient package · Issue #4017 · dotnet/SqlClient · GitHub
Skip to content

Remove dependencies to Microsoft.IdentityModel from main SqlClient package #4017

Description

@ErikEJ

Would be great to not have these in the main package

Edited by @mdaigle:
Tracks work to remove Microsoft.IdentityModel.JsonWebTokens and Microsoft.IdentityModel.Protocols.OpenIdConnect from the core Microsoft.Data.SqlClient package.

Azure.Identity, Azure.Core, and Microsoft.Identity.Client dependencies were previously removed from the core Microsoft.Data.SqlClient package as part of #1108.

Activity

  1. moved this from To triage to Needs Response in SqlClient Boardon Mar 9, 2026
  2. moved this from Needs Response to Investigating in SqlClient Boardon Mar 9, 2026
  3. moved this from Investigating to Backlog in SqlClient Boardon Mar 10, 2026
  4. cremor commented on Mar 14, 2026

    @cremor

    This should be in version 7.0 because it was part of the original design for the Azure package removal: #3579

  5. ErikEJ commented on Mar 14, 2026

    @ErikEJ
    ContributorAuthor

    @cremor too late for that. Will probably be in version 8

  6. changed the issue type fromtoon Mar 16, 2026
  7. NXTwoThou commented on Jun 3, 2026

    @NXTwoThou

    @cremor too late for that. Will probably be in version 8

    Any idea on timeline for 8? We're now two versions into Microsoft.IdentityModel.Protocols.OpenIdConnect that can't update AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#3512 It would be nice to get rid of this all together.

  8. ErikEJ commented on Jun 3, 2026

    @ErikEJ
    ContributorAuthor

    @NXTwoThou That looks like a point in time issue...

  9. NXTwoThou commented on Jun 3, 2026

    @NXTwoThou

    @NXTwoThou That looks like a point in time issue...

    Two days and two versions worth of. :P

  10. rozeboosje commented on Jun 3, 2026

    @rozeboosje

    Yes it's pretty shocking that something that breaks so much can be left in place for nearly 2 days now.

  11. 2 remaining items

  12. github-actions commented on Sep 17, 2026

    @github-actions

    🔍 Triage Summary (on-demand re-triage)

    Check Result
    Issue type Feature
    Environment Not applicable (feature/dependency-removal request, not a bug report)
    Area Area\Engineering
    Duplicates Related (not duplicate): #3579 (original Azure package removal design), #4448 (remove Azure.Identity from Microsoft.Data.SqlClient.Extensions.Azure)
    Regression Not applicable

    Analysis

    This issue requests removing the Microsoft.IdentityModel.JsonWebTokens and Microsoft.IdentityModel.Protocols.OpenIdConnect dependencies from the core Microsoft.Data.SqlClient package, continuing the dependency-slimming work started in #1108 (which removed Azure.Identity, Azure.Core, and Microsoft.Identity.Client). This is a package/engineering-level change affecting the dependency graph and likely the Entra ID authentication code paths, rather than a runtime bug. It is already labeled Breaking Change :hammer:, correctly reflecting that removing these dependencies would require consumers using affected auth flows to add an extension package. Severity/priority: P2 (planned engineering work with active community interest, not an active regression).

    Next Steps

    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 #4017 · copilot · auto · 36.6 AIC · ⌖ 13.1 AIC · ⊞ 11.9K · ◷

  13. virzak commented on Oct 5, 2026

    @virzak
    Contributor

    I'd like to take this on.

    All the Microsoft.IdentityModel usage lives in AzureAttestationBasedEnclaveProvider.cs, which the #2247 proof of concept already moved out of the core build along with the auth providers. The #1108 split moved the auth half; this would finish it. EnclaveDelegate.GetEnclaveProvider creates the provider directly for SqlConnectionAttestationProtocol.AAS.

    My proposal is to move the provider into Microsoft.Data.SqlClient.Extensions.Azure and have the core load it the same way SqlAuthenticationProviderManager already loads that package: by assembly name, throwing EnclaveProviderNotFound with a "reference Microsoft.Data.SqlClient.Extensions.Azure" hint if it isn't there. HGS and None attestation would stay in the core. Anyone who doesn't use AAS attestation loses the IdentityModel dependencies on upgrade, and AAS users add one package reference.

    Unless you'd prefer otherwise, I'll go with Extensions.Azure and assume this targets v8 since it's breaking. The alternative is a separate package so AAS users don't pull in Azure.Identity (see #4448). I'll open a draft PR so the approach can be discussed against real code.

    @edwardneal, #4438 and the follow-up you mentioned touch the same provider hierarchy. I'm happy to build on top of them instead of conflicting, so let me know the order you'd prefer.

  14. added this to the 8.0.0-preview1 milestone on Oct 5, 2026
  15. edwardneal commented on Oct 6, 2026

    @edwardneal
    Contributor

    Thanks @virzak. I think we're dealing with the same point in two ways.

    I've been referencing the SqlColumnEncryptionEnclaveProvider class in System.Data.SqlClient. This was public in the netfx library, and it's internal in Microsoft.Data.SqlClient. I'd been working on the assumption that we'd expose SqlColumnEncryptionEnclaveProvider publicly and that the AAS provider would inherit from it.

    Some of my work actually came from CreateEnclaveSession. We wouldn't be able to expose it publicly via netstandard2.0 because the method signature includes an ECDiffieHellman type, and netstandard2.0 doesn't include that type. I changed the method signature and I was starting to refactor the type hierarchy to remove its duplicate code when #4541 and #4621 came up.

    Once #4621 is ready, I'll rework #4438 as needed. I don't think this'll make a vast difference to your work - I think the NativeAOT compatibility mechanisms will actually have a larger impact, although I'm not sure exactly what that'll look like.

  16. virzak commented on Oct 6, 2026

    @virzak
    Contributor

    Makes sense. Once SqlColumnEncryptionEnclaveProvider is public, the AAS provider can move into Extensions.Azure whole and the reflection binding in #4790 goes away. Happy for #4790 to be the interim step and to rebase onto your rework and Paul's NativeAOT switch when they land.

  17. added a commit that references this issue on Oct 8, 2026
    ef57d69
  18. added a commit that references this issue on Oct 21, 2026
    d3074cd
  19. gabbsmo commented on Oct 22, 2026

    @gabbsmo

    Today we updated from .NET 8 to .NET 10. Since then our build output increased from ~150 MB to ~250 MB. The main culprit seems to be assets in Microsoft.Identity.Client.NativeInterop.

    > dotnet nuget why Microsoft.Identity.Client.NativeInterop
    Microsoft.EntityFrameworkCore.SqlServer (v10.0.13)           
    └── Microsoft.Data.SqlClient (v6.1.7)                        
        └── Microsoft.Identity.Client.Broker (v4.84.2)           
            └── Microsoft.Identity.Client.NativeInterop (v0.20.6)
    

    My understanding is that this is only used for interactive Windows authentication. For our case we can exclude them by adding <PackageReference Include="Microsoft.Identity.Client.NativeInterop" Version="0.20.6" ExcludeAssets="native" /> to the project file(s).

    However, this is more a workaround than a solution. Pinning what should be transitive dependency is not great and it cannot (at least easily) be applied to EF Core migration bundles as they build the project at runtime.

  20. ErikEJ commented on Oct 22, 2026

    @ErikEJ
    ContributorAuthor

    @gabbsmo Use Microsoft.Data.SqlClient 7.x, it does not include any Azure dependencies

  21. added a commit that references this issue on Oct 22, 2026
    846c28a
  22. moved this from In progress to Done in SqlClient Boardon Oct 22, 2026
  23. gabbsmo commented on Oct 23, 2026

    @gabbsmo

    @ErikEJ Thanks! Found that it is even the official workaround.

    For anyone else searching on this issue, you may need to pin the latest Azure.Core if you get errors about Managed Identity. See Azure/azure-sdk-for-net#60650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Breaking Change 🔨Issues/PRs that are related with breaking API changes in the driver.

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions