Azure interactive logins call the MSAL function AcquireTokenInteractive. The source code comments clearly explain the differences in default behaviour between browsers and .NET versions vis whether an embedded browser or the system browser is used for login. But in all cases, SqlClient does use the default behaviour of MSAL.
It would be better if the consumer application could choose whether an integrated or system browser is used, and this is supported by MSAL via WithUseEmbeddedWebView. What is missing is an option for the consumer to choose the behaviour here.
There is currently no alternative apart from to accept the default, or fork SqlClient and make the change ourselves.
At a higher level, this same feature was added to Azure.Identity based on our feature request so I believe that shows the worth in the idea. It's not an option here since SqlClient uses MSAL directly without an intermediate library (as far as I can tell).
Azure interactive logins call the MSAL function
AcquireTokenInteractive
. The source code comments clearly explain the differences in default behaviour between browsers and .NET versions vis whether an embedded browser or the system browser is used for login. But in all cases,SqlClient
does use the default behaviour of MSAL.It would be better if the consumer application could choose whether an integrated or system browser is used, and this is supported by MSAL via WithUseEmbeddedWebView. What is missing is an option for the consumer to choose the behaviour here.
There is currently no alternative apart from to accept the default, or fork
SqlClient
and make the change ourselves.At a higher level, this same feature was added to Azure.Identity based on our feature request so I believe that shows the worth in the idea. It's not an option here since
SqlClient
uses MSAL directly without an intermediate library (as far as I can tell).