[Feature Request] In Identity.Client project change “net6.0-windows10.0.17763.0” to just “net6.0-windows”

[SameerK-MSFT]

Is your feature request related to a problem? Please describe.
Yes. Removed dependency on Window platforms

Describe the solution you'd like
change “net6.0-windows10.0.17763.0” to just “net6.0-windows”

Describe alternatives you've considered
NA

[SameerK-MSFT]

Fixed in #3984

[mgroetan]

@SameerK-MSFT, I'm noticing a distinct change in behaviour in the 4.52.0 version, which I suspect is due to this feature request.
Up to and including 4.51.0, if you targeted "net6.0-windows" and DID NOT request an embedded web view to be used, you would be taken to a newly opened system default browser tab.

Whereas from 4.52.0 (and onward), if you do the same, you get presented with a popup embedded web view.

To me this feels like a breaking change, as NOT using the embedded web view was previously the default, which is not the case any more.

For both 4.51.0 and 4.52.0, the builder's "Parameters.UseEmbeddedWebView" defaults to "NotSpecified".

If I want to keep the same default behaviour as in 4.51.0, I need to perform this additional configuration:
.WithUseEmbeddedWebView(false)
Upon which the builder's "Parameters.UseEmbeddedWebView" changes to "System".

Have I misunderstood something, or is this indeed an undocumented breaking change?
Should I be interpreting the (unchanged) XML doc of the "WithUseEmbeddedWebView" method to implicitly understand the changed behaviour?

        /// <param name="useEmbeddedWebView">If <c>true</c>, will use an embedded web browser,
        /// otherwise will attempt to use a system web browser. The default depends on the platform:
        /// <c>false</c> for Xamarin.iOS and Xamarin.Android, and <c>true</c> for .NET Framework,
        /// and UWP</param>

[bgavrilMS]

@mgroetan - we changed the default webview indeed, because we made some changes to the target framework of MSAL, from net6-windows10.0.176630.0 to net6-windows.

We expected that it will not break apps. Were we wrong?

[mgroetan]

@bgavrilMS Well, apps are not broken, technically speaking. But in our case, we at some point went away from a custom embedded web view-based implementation in favour of MSAL, which used a system browser by default, unless you explicitly stated that you wanted an embedded web view,

We did that change for security reasons, obviously, as you shouldn't be using an embedded web view these days, as per the recommendation by the IETF: https://www.rfc-editor.org/rfc/rfc8252.txt (section 4)
In short:
"For authorizing users in native apps, the best current practice is to
perform the OAuth authorization request in an external user-agent
(typically the browser) rather than an embedded user-agent (such as
one implemented with web-views).

Previously, it was common for native apps to use embedded user-agents
(commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app. See Section 8.12"

Note also that the RFC was written in 2017, so already six years ago, you shouldn't be using embedded web views...

That in itself dictates that the default should indeed be to NOT use an embedded web view, like you were already doing.
Whereas now, if no one changes their code, their apps will suddenly start using an embedded web view nonetheless, thereby downgrading their security stance.

[bgavrilMS]

Ack, thanks for the reference. There aren't actually any known issues with a legitimate app using embedded webview, only with malicious app using webview. But then again, a malicious app already installed can do much more damage, e.g. it can redirect your to a hacked authorization endpoint to steal username / password using the system browser.

But I agree we could have handled the transition from net6-windowsXYZ to net6-windows better, possibly by taking a breaking change.