Allow Specifying AAD authentication Methods via ChainedTokenCredential in Microsoft.Data.SqlClient 3.0

[bdschaap]

Microsoft.Data.SqlClient 3.0 now supports DefaultAzureCredential. This is very useful but I'd like to suggest providing some control over the AAD authentication methods used through ChainedTokenCredential.

[cheenamalhotra]

Hi @bdschaap

We've thought about this and have some ideas to introduce generalized TokenCredential support in future [still in ideation phase].

However, in the meantime, you can generate your own Access Token using ChainedTokenCredential or anything of your choice and pass it over to driver with SqlConnection.AccessToken connection property.

[victorp13]

I'm not sure if this pertains to the same, but it would be ideal to be able to specify auth methods (and their order) with the new "Authentication=Active Directory Default;" SQL connection string property. Using that authentication with local VS Code development leads to a considerable loading time increase each time we start an application. Would be great to be able to locally prioritize VisualStudioCodeCredential via the SQL connection string.

[bdschaap]

I think that's great idea

[sopelt]

For local development it would be great if an actual credential type or exclusion could be configured. The credential chain causes quite a bit of noise and transient exceptions in diagnostics/logging for failed attempts (e.g. trying the MSI private network).

[lcheunglci]

I believe there was a draft PR #1260 that would open up this scenario, but more resources and time is needed to develop it.

[Xriuk]

For local development it would be great if an actual credential type or exclusion could be configured. The credential chain causes quite a bit of noise and transient exceptions in diagnostics/logging for failed attempts (e.g. trying the MSI private network).

This, because at least for me Visual Studio credentials are not working, even if they should. It just keeps disconnecting, very frustrating not being able to disable it.