SSO is not working correctly when attempting Azure AD SAML logons

[akunadze]

Description
We're using WebView2 to facilitate app-based SAML logons to Azure AD.
The code is C++ and is a fairly straight-forward use of the API. The two salient points are:

1. We use options->put_AllowSingleSignOnUsingOSPrimaryAccount() to allow/disallow automatic login with desktop creds (depending on user settings)
2. We add a WebResourceRequested handler with "*" filter.

There are two problems:

1. put_AllowSingleSignOnUsingOSPrimaryAccount worked perfectly up until Runtime 88.0.705 or so. Now it seems to always provide the desktop creds, regardless of the setting. We've worked around that by removing x-ms-RefreshTokenCredential HTTP header, but that is less than ideal.

2. SAML has two initiation modes: GET and POST. In the GET mode the encode XML authentication request is provided as a URL parameter. In the POST mode - as post data. Strangely, SSO works fine in POST mode, but in GET mode it works only if WebResourceRequested handler is not invoked for the initial request, even if it's just an empty method returning S_OK. This one is a lot harder to work around as the handler is normally used for several vital tasks.

Version
SDK: 1.0.824-prerelease
Runtime: 89.0.774.75
Framework: Win32
OS: Win10

Repro Steps
Note: run on a machine with Azure AD user logged in
Create a minimal Win32 WebView2 application using put_AllowSingleSignOnUsingOSPrimaryAccount(FALSE)
Navigate to the URL (see below)
Expected: Microsoft login prompt
Actual: Automatic login with OS credentials

Now set put_AllowSingleSignOnUsingOSPrimaryAccount(TRUE)
Add AddWebResourceRequestedFilter(L"*", COREWEBVIEW2_WEB_RESOURCE_CONTEXT_ALL);
Add an empty WebResourceRequested handler
Navigate to the URL (see below)
Expected: Automatic login with OS credentials
Actual: Microsoft login prompt

Here's the URL we use for GET method testing:
https://login.microsoftonline.com/af2c475f-4b36-40b1-93a0-dfe546287b16/saml2?SAMLRequest=fZJNb9sgGMfv%2BxQWd2wM2BgUp8padYvWpVHjdtIuFcbQotmQGRJ1336J02jrJUfg%2Bb%2BI3zO7ehv6ZK%2FHYL2rQZ4ikGinfGfdSw0em1tYgav5p1mQQ4%2B3YrGLr%2B5B%2F97pEJNFCHqMB921d2E36HGjx71V%2BvHhrgavMW6DyLIfyxVcXd8%2F0RXZfPvCs6NR1vsX60Byc3CxTsYp%2BiyY3tLBqtEHb6J3vXU6VX7IpMGKssJA2pISUtTmkBOJYGd0QUtcsTYvJ38Mkls%2FKj21rYGRfdAgWd7U4PkwiYzR2LRlV3WMGYWx6hBhCGFCGSeM5rRCBWEc4y4vNUOq7AqpCTGEkvyZlNyYoqugYS2DlFcYVrJoYVlRXXGuCFf8kBXWMgS71%2F%2FSQ9jppQtRulgDjHAOEYU5bjASmAnCUlrwnyBZjz565fvP1p0Y7EYnvAw2CCcHHURUYrP4fidwikR7Ggria9Os4fp%2B04Dk6cwSH1ke6LogTvQue23fg8H8BFtMjcfjTw4yXtYeb2wHzTQqtIs2%2FvmQfVkuz4sE5rLXb7%2FgUQPDdpb932T%2Bfvy4hfO%2F&SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256&Signature=H6UNYOSe3XxlcNna7H910mXB02L6fZJLZk7S8rEcY2tgY%2BDIEgsgSPUfsPeuMKNsPpsejf8CRItGiT%2B92CNHJov6e%2FxkEVfPqsGtkIzO8HEcnp55r%2FxUPtnzBflFgxVu3bd5Ci7XO%2Bh6%2B1tZC2mIZcy0NX0K0kCy5%2Fwo6Oq1NrPG2knYR8HjNhZ3MH1oUqpX1eonTXyjpfbjaZv1a58dzzyQYOyxO77L2HJOlryrqdcWpGftY4YYgDE8Cjro7uqWzxjlBmOtaqwIXZLulz8NtFjeIbCe%2FUlGckhTuMvmVGmj9sSryChO%2FVP7zPuKZC7ZMHJ7J%2BJvRqT82mPT%2BXefjAGEVZ5bd0jLEbGZytkK4sgrQKDg%2BVIcFii7Uw18BANCLdZzd7plwnDahA02p0TlFWucoPLSxcU%2Fc4Rb2EA8vhEjFTkDLF3%2BcYlErtLxTxSeW2JJ%2B3Rf6Q2NlkSHACIlfFrLr7zVR48uBPlBSwIiPG0cyg6vHgdPDcUyAfd%2F1T9O%2FwH0M705J%2B4Tp8lt84sSmLUzitDNZUKn%2FSgKcXPC2u4lESgaLytxivjrwMDoJiRwdI6%2BaDcr%2Fr%2Bd9X%2BnAd8lSlI2odU2mJxNpLMVlwhgDc8dUVqC2bTMzXYJe3KoWccJBlPdIZnqJmNljqiRGaX6PEog1lf0u3%2F3GOkbQvt6l%2BI%3D

AB#32524700

[champnic]

Thanks for the bug report @akunadze! I've put it on our backlog and we'll take a look quickly.

[champnic]

This also sounds like it might be the same issue as #1125.

[champnic]

This is fixed in runtimes 92.0.892.0+. Thanks!