Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bdschaap opened this issue Jun 8, 2021 · 7 comments
Labels
💡 Enhancement Issues that are feature requests for the drivers we maintain.

Comments

@bdschaap
Copy link

bdschaap commented Jun 8, 2021

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
Copy link
Member

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.

@cheenamalhotra cheenamalhotra added the 💡 Enhancement Issues that are feature requests for the drivers we maintain. label Jun 8, 2021
@victorp13
Copy link

victorp13 commented Jun 11, 2021

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
Copy link
Author

I think that's great idea

@sopelt
Copy link

sopelt commented Nov 10, 2022

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
Copy link
Contributor

lcheunglci commented Nov 10, 2022

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
Copy link

Xriuk commented May 12, 2023

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.

@David-Engel
Copy link
Contributor

For further customization of token acquisition, users should use AccessTokenCallback to provide their own mechanism of acquiring an access token.

@David-Engel David-Engel closed this as not planned Won't fix, can't repro, duplicate, stale Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 Enhancement Issues that are feature requests for the drivers we maintain.
Projects
Development

No branches or pull requests

7 participants