Microsoft-authentication-library-for-dotnet: [Feature Request] WebView2 embedded browser

[jmprieur]

Is your feature request related to a problem? Please describe.

On the desktop, an embedded browser only exists on .net45 and it is using an old version of Internet Explorer.

We need an embedded browser that:

• also work on .Net Core on Windows
• uses Edge as the actual engine (Edge is needed to satisfy the Fido scenario)

This browser is WebView2.

Stream of work:

• [ ] Refactor current WebBrowser implementation to extract out marshalling to UI thread and maybe hosting in a panel
• [ ] Add a WebView2 implementation of embedded browser on .NET Fx and .NET 5 https://docs.microsoft.com/en-us/microsoft-edge/webview2/gettingstarted/win32. Currently thinking it should go in the box with .NET Fx.
• [ ] Change the WebUiFactory to prefer WebView2 if it is installed
• [ ] Docs and log messages to tell ppl how to install WebView2
• [ ] (Stretch goal) Add an WithEmbeddedWebViewOptions to MSAL that exposes an enum stating "PreferredBrowser" with values - Auto (default) - which means automatic fallback to WebBrowser, WebView2, LegacyWebBrowser.

• [ ] (Stretch goal) Change MSAL.Desktop to add support for WebView2 on .net core 3.1. We should have 1 method that pull in all the MSAL.Desktop functionality, smth like .WithDesktopFeatures()

• Goal for MSAL 5 - review the default browser selection. For example for B2C we should no longer allow LegacyWebBrowser as it is unusable.

@henrik-me @jmprieur to review the stretch goals.

Technical aspects:

You can use GetAvailableCoreWebView2BrowserVersionString/CoreWebView2Environment.GetAvailableBrowserVersionString to detect if a compatible version of the browser or runtime is installed.]
How can we disable:
o The context menu
CoreWebView2Settings.AreDefaultContextMenusEnabled]
o The developer tools (F12)
CoreWebView2Settings.AreDevToolsEnabled]
o The go back / go forward keys
I don’t think we have a way to do this one.]

Is there an equivalent to WebBrowser.DocumentTitleChanged and WebBrowser.Title ?
[davris: Yes DocumentTitle and DocumentTitleChanged]

[jmprieur]

See also;

• https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1213
• https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.application.sethighdpimode?view=netcore-3.0#System_Windows_Forms_Application_SetHighDpiMode_System_Windows_Forms_HighDpiMode_

[bgavrilMS]

1. I agree with adding a new platform, but we should be wary of adding a new SKU (x-ms-client-sku). While this will give us better telemetry, AAD has so many feature flags that are tied to the SKU string that it will be a bug farm to find them all.

2. We might have to use a WPF panel instead of a WinForms panel if we want high DPI support.

[jmprieur]

@bgavrilMS :
For 1, which SKU would we reuse? (Desktop, I'm assuming) ?
For 2, I believe that .NET Core 3.0 supports HDPI (see the link above)

[bgavrilMS]

For 1, I would reuse the .net core SKU, which is MSAL.NetCore

[bgavrilMS]

Probably blocked by https://github.com/onovotny/MSBuildSdkExtras/issues/191
Work can still happen, but we won't be able to pack.

[trickpatty]

I see that this work is blocked for the time being. Is there a workaround that you might suggest in order to use this package in a .NET Core 3.0 project?

[jmprieur]

@trickpatty : You can actually use MSAL.NET in a .NET Core 3.0 project already. We have several samples which were updated and work perfectly fine:

• ASP.NET Core Web API tutorial
• .|NET Core daemon app tutorial](https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2)
  and we are upgrading the |ASP.NET Core Web app tutorial](https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2) at the moment

This work item is about supporting the embedded browser control on Windows on providing an extra target to benefit from crypto operations which are more reliable on all OS where .NET Core 3 is supported (today there can be a difference of behavior depending on the .NET framework version. See Also https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1453

[bgavrilMS]

I renamed the feature request to make it more clear. @jmprieur "better crypto" is not well defined, is there a specific benefit that you have in mind?

[jmprieur]

Thanks @bgavrilMS : I've updated my comment.

[henrik-me]

Important info regarding the timeline:
We are currently prioritizing work that will enable us to ship a netcore 3 target without a dependency on WinForms of WPF for our confidential client (web app/service scenarios).

[henrik-me]

@jmprieur : Thinking this feature should be solely about supporting Edge? Perhaps a separate feature to potentially support a specific netcore3/3.1 target/netstandard?

Asides:
For WebView2 (Edge Chromium): https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
For WebView (Wrapping UWP controls in WinForms and WPF): https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/wpf-winforms/webview

[jmprieur]

@henrik-me : yes, Edge or Chronium?

[bgavrilMS]

Deliverable 1: Edge on Windows (by copying the .net classic implementation into the extension library)
Deliverable 2: (needs a spike) Edge Chromium on Windows via webview2
Deliverable 3: (needs a spike) Support for Mac and Linux via https://github.com/SteveSandersonMS/WebWindow (thanks @mjcheetham )

I think this work item covers deliverable 1. Personally I would spike deliverable 3 directly before 2.

[JeffMushmo]

With this capability, does it mean we won't have to setup AAD to redirect to http://localhost?

[jmprieur]

yes, @JeffMushmo : you'll have the capability of using an embedded browser (which redirect URI will be https://login.microsoftonline.com/common/oauth2/nativeclient

[bgavrilMS]

you can find an implementation for this here: https://identitydivision.visualstudio.com/Engineering/_workitems/edit/824799

[akaviny]

Will this also cover the case of .Net 5? No embedded browser is displayed with an experimental WinUI 3 Desktop app. The AcquireTokenInteractive call results in a MsalClientException of

Only loopback redirect uri is supported, but urn:ietf:wg:oauth:2.0:oob was found. Configure http://localhost or http://localhost:port both during app registration and when you create the PublicClientApplication object. See https://aka.ms/msal-net-os-browser for details

[bgavrilMS]

My undertanding is that .net 5 is the next version of .net core, which also includes support for mono etc. The work proposed here is for .net core 3.1, so .net 5 would benefit from it as well.

[bgavrilMS]

I spent some time looking at this, here are my conclusions:

Strategy of using a WinForms based web-browser:

1. MSAL's current implementation of embedded webview is based on the WebBrowser from .net classic can be ported to .net core with no changes (just need to update the build targets to publish the DLL) [Productization 1/2 day]. This webview still uses IE !!!!
2. A new control called WebViewControl exists and I have a rough prototype with it (on .net core, but should work on .net classic as well). This uses the "old" Edge. [Productization time would be 2-3 days for me]. LATER UPDATE - this control has been deprecated.

Strategy of using a similar approach on Mac and Linux:

1. Embedding a web browser control in a native window can be done on Mac and Linux as well
2. The most advanced work I've seen in this space is here: https://github.com/JBildstein/SpiderEye, however the native controls are missing a key feature required for MSAL to intercercept the auth code

Strategy of using WebWindow

WebWindow is a standardized web control that should be available on all operating systems. Blazor can use it.

However, as an independent control, users need to install Microsoft Edge Canary version.

I'd say this approach is promising, but not yet ready for prime time.

Bundle Chromium

https://github.com/chromelyapps/Chromely looks promising, but the size of the app is pretty big. Out of the box experience needs to download assemblies first. Also API is heavily focused on installing

Other strategies

A very good investigation by the Blazor folks - https://blog.stevensanderson.com/2019/11/01/exploring-lighter-alternatives-to-electron-for-hosting-a-blazor-desktop-app/

[jennyf19]

@bgavrilMS this is awesome. did you put this in the wiki?

[bgavrilMS]

@jmprieur - no, I don't think this is for the wiki, as it is not consumable by developers at this point.

[bgavrilMS]

I've investigated this more and found out that WebView, WebViewControl and WebViewCompatible are all deprecated in favour of WebView2. Guidance from the product group is to not use WebView control for new apps.

Currently WebView2 is in preview and the .NET support is expected to GA around December 2020.

Unlike our current implementation (i.e. WebBrowser), which is based on a browser that is always present on the box, the WebView2 runtime needs to be installed. App installers will have an option to install it.

[jmprieur]

@bgavrilMS adding documentation on how to install the required components for WebView2: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#understanding-the-webview2-runtime

[bgavrilMS]

WebView2 has GA-ed. Let's try to use it in 4.24

[Xanen]

I see that 4.24 has released but it appears this didn't make the cut. Using Google as an IDP via an embedded browser on desktop has been broken for quite some time now. I believe the issue was originally reported here: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1561. It's been causing a lot of problems for users of my app that have had to create new accounts because their Google login stopped working. Any updates? Will this be addressed in 4.25? Is there anything that can be done in the meantime apart from using the System browser? That's not really a user-experience I'd feel comfortable pushing out. Thanks!

[jmprieur]

@Xanen. for the moment, you'd need to use the system browser.
We are prioritizing implementing the embedded browser, though. @bgavrilMS will elaborate on when this would be available;

[henrik-me]

@jmprieur @bgavrilMS : If google disallows embedded browsers this feature is not for the scenario @Xanen mentions? Not sure if WAM will work in that case either? Not sure how the Google IDP issue can be solved outside of using the System Browser as that is what Google wants people to use, also it's what Google does for all their own services (afaik).

[Xanen]

Fwiw, the google drive desktop app does not require opening the system browser (but does provide the option to do so).

[henrik-me]

It's possible they have their own app on an allowlist.

[bgavrilMS]

WAM cannot be used with b2c (i'll follow this up). ETA for WebView2 is this quarter.

[jmprieur]

• [x] factory to choose the old and new control
• [x] implementation in .NET classic
• [x] implementation on .NET 5