MSAL.NET uses web browser

Web browsers in MSAL.NET

There is one important thing that beginners with authentication libraries and Azure AD don't immediately understand: this is the fact that when getting token interactively, the content of the dialog box is not provided by the library, but really by the STS: the authentication endpoint sends some HTML and JavaScript which control the interaction. Delegating this dialog (this dance) to the STS has many advantages:

• enabling redirections to other identity providers (for instance login-in with a work school account or a personal account with MSAL, or with a social account with B2C)
• letting the STS control conditional access, for instance by having the user do multiple factor authentication during this authentication phase (entering a windows hello pin, or being called on his phone, or on an authentication app on his phone). In cases where multi factor authentication is required and the user has not set it up yet, s/he can even set it up just in time in the same dialog, entering his mobile phone number, and being guided to install an authentication application and scan a QR tag to add his account. This is an amazing experience!
• Letting the user change his password in this same dialog when the password has expired (providing additional fields for the old password and the new password)
• Enabling branding of the tenant, or the application (images) controlled by the Azure AD tenant admin / application owner.
• Enabling the user to consent to let the application access resources / scopes in his name just after the authentication.
• Last but not least, the password (if one was typed) is never stored by the application, nor the library.

To host this interaction with the STS, ADAL.NET uses an embedded web browser. For all the platforms that provide UI (read not .NET Core), a dialog is provided by the library embedding a Web browser control. MSAL.NET also uses an embedded web view for the .NET Desktop, and WAB for the UWP platforms and windows phone 8.1 applications, but leverages the system web browser for Xamarin iOS and Xamarin Android applications. Using the system web view has the big advantage of sharing the SSO state with other applications and with web applications without needing a browser. This was done in the Xamarin iOS and Xamarin Android platforms because on those, the system web browser occupies the whole screen, and the user experience is good. The system web view is not distinguishable from a dialog. For desktop applications, however, launching a System web view leads to a very weird user experience, as the user sees the browser, where he might already have other tabs opened, and there he gets a page asking him/her to close this window. If he does not pay attention, s/he can close the whole browser (including other tabs which are unrelated to the authentication). This would also require opening local ports and listening on them, which might require advanced permissions for the application. Note, finally, that for .NET Core, acquisition of tokens interactively is not available. Indeed, .NET Core does not provide UI yet.