[Problem/Bug]: AllowSingleSignOnUsingOSPrimaryAccount false doesn't work, systems microsoft account is always used!

[haefele]

What happened?

We have a application where users can login using OIDC and M365.

If the systems microsoft account is correct, setting AllowSingleSignOnUsingOSPrimaryAccount to true works great. The user doesn't have to enter his credentials again, he is just logged in automatically - nice.

But, we also anticipated the opposite: What if the windows user should not be used and you want to login with a different microsoft account. For this situation, we added a setting to our app where the user can basically enable/disable AllowSingleSignOnUsingOSPrimaryAccount.

It works fine for most of our machines and environments. But one of our customers has a bunch of machines, where despite AllowSingleSignOnUsingOSPrimaryAccount being set to false, it still uses the systems microsoft account.

So basically, our user can't login, because the systems microsoft account is always used, no matter the value of AllowSingleSignOnUsingOSPrimaryAccount.

What we already tried:

1. We added logging to the application, to make sure that AllowSingleSignOnUsingOSPrimaryAccount is definitely set to false - it is.
2. I read here that you can also enable edge browser features through the registry or environment variables. In my own tests, I could reproduce the problem by setting the environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS to --enable-features=msSingleSignOnOSForPrimaryAccountIsShared. Now our application would always use my systems microsoft account, even if my application sets AllowSingleSignOnUsingOSPrimaryAccount to false - exactly what happens with our customer! Unfortunately, on the machines where this problem happens, this environment variable is not set, and also no registry value either.

This problem seems very similar to #1125 - but that bug has been fixed long ago, and we verified that on the machines with the problem, the latest evergreen WebView2 runtime is installed.

At this point, we are very much out of ideas. Are there any other ways additional browser args can be passed to WebView2 instances, that can overwrite our own configuration?

Is there any way I could check through injected JavaScript code whether the feature msSingleSignOnOSForPrimaryAccountIsShared is enabled?

Any help would be very much appreciated, so our customer is able to use our application again.

Our code

Here is the full code we use for the WebView2 initialization. You can even see all our logging, and an attempt to work around the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable.

protected override async Task OnViewAttached()
{
    this._userDataFolder = WebView2Helper.GetUserDataFolder(this._applicationOptions.CurrentValue, "OAuth");

    if (Environment.GetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS") is not null)
    {
        this._logger.LogWarning("Suspicious environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS is set, could impact our WebView2, so we clear the environment variable");
        Environment.SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", null); // Clear it, we don't want it to impact our WebView2
    }

    var options = new CoreWebView2EnvironmentOptions()
    {
        AllowSingleSignOnUsingOSPrimaryAccount = this._applicationOptions.CurrentValue.AllowSingleSignOnUsingOSPrimaryAccount,
    };
    var env = await CoreWebView2Environment.CreateAsync(
        browserExecutableFolder: null,
        this._userDataFolder,
        options);

    await this.View.WebView.EnsureCoreWebView2Async(env);
    this._logger.LogInformation("OAuth WebView2 ({Version}) environment created with SSO {SSO} at {UserDataFolder}", env.BrowserVersionString, options.AllowSingleSignOnUsingOSPrimaryAccount, this._userDataFolder);

    this.View.WebView.NavigationStarting += this.WebView_OnNavigationStarting;
    this.View.WebView.Source = new Uri(this._args.AuthorizeUrl);
}

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

131.0.2903.86

SDK Version

1.0.2792.45

Framework

WPF

Operating System

Windows Server

OS Version

No response

Repro steps

Create a new WPF application and initialize the WebView2 like this:

private async Task Loaded()
{
    var userDataFolder = WebView2Helper.GetUserDataFolder();

    var options = new CoreWebView2EnvironmentOptions()
    {
        AllowSingleSignOnUsingOSPrimaryAccount = false, // Important!
    };
    var env = await CoreWebView2Environment.CreateAsync(
        browserExecutableFolder: null,
        userDataFolder,
        options);

    await this.WebView.EnsureCoreWebView2Async(env);

    // Microsoft login page
    this.WebView.Source = new Uri("https://www.microsoft.com/cascadeauth/store/account/signin?ru=https%3A%2F%2Fwww.microsoft.com%2Fde-de%2F");
}

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

[haefele]

Any updates on this?

[haefele]

As far as I can tell, the only way around this issue is, to use a different embedded browser. But doesn't that kinda defeat the whole purpose of WebView2?

@sivMSFT @champnic

[vaibhav-rajgolkar]

@haefele Did you find any solution for the problem? It looks like Seamless SSO is enabled for the domain mentioned in issues.

As far as I can tell, the only way around this issue is, to use a different embedded browser. Can you elaborate more on this? Do you mean using something else other than WebView2/Edge based browser?

Not sure if any of the below would help in case:

1. Pass --disable-features=msSingleSignOnOSForPrimaryAccountIsShared via AdditionalBrowserArguments while WebView2 creation.
2. Setting InPrivate Mode for the WebView2 ( link )

[haefele]

I did unfortunately not find a solution to this problem ☹️

Seamless SSO actually looks like it could be related - good catch, I had no clue this existed.

Can you elaborate more on this? Do you mean using something else other than WebView2/Edge based browser? Yes, that's what I was suggesting. Using embedded Chromium for example just to avoid this "automatically logged in" situation.

I tried everything possible related to msSingleSignOnOSForPrimaryAccountIsShared, but all without any luck. The issue still persisted. I did not try out the InPrivate mode.

Honestly, I don't know if my customer still experiences this issue. As you can tell from when I created this issue, it's been a while.