[Bug] Log-in window is sometimes left running by itself/orphaned

[myokeeh]

I'm experimenting with WinappSDK / WinUI3. Coming from UWP, one odd thing I've noticed is sometimes when my app closes/crashes, the MSAL sign-in window is left running on its own/orphaned. Why does that happen and is there a way to prevent it?

Which version of MSAL.NET are you using? 4.49.1-preview

Platform WinappSDK 1.3 expermintal1, WinUI3

** Repro ** It repros fine with a console app.

    static async Task Main(string[] args)
    {
            var pca = PublicClientApplicationBuilder
                .Create("4b0db8c2-9f26-4417-8bde-3f0e3656f8e0")
                .WithRedirectUri("http://localhost")
                .WithBrokerPreview(true)
                .Build();

            var result = pca.AcquireTokenInteractive(new[] { "user.read" })
                .WithParentActivityOrWindow(GetConsoleOrTerminalWindow())
                .ExecuteAsync();
           
            // WAM account picker pops up here.
            await Task.Delay(1000);

            // app crashes, but instead of closing, both console and Account picker remain on the screen. Console is modal.
            throw new Exception("oh no");
    }

Actual: when app crashes, the account picker stays on screen and so does the console window, which remains modal. Account Picker seems to be blocking the window from closing after the crash. App appears "frozen"

Expected: on app crash, Account picker and app should close.

[pmaytak]

Which sign-in window is it: embedded web view, WAM, WAM preview? Which TFM is this, net7.0-windowsX?

[myokeeh]

It's the WAM Preview using Microsoft.Identity.Client.Broker 4.49.1-preview but I know this also happened on the last few previews. It's net7.0-windows10.0.22621.0 but also had the same issue on net6.0-windows10.0.22621.0

A quick way to reproduce for me is when the Log-in screen is shown, I can go to Task Manager and quit the app and the log-in window does not go away. In fact, I can still interact with it, move it around, and complete the sign in process, but not useful at that point.

[bgavrilMS]

Which windows is it @myokeeh ? The flow with WAM uses a Windows component called Account Picker to list all the accounts in Windows.

Account picker

WAM windows

[myokeeh]

@bgavrilMS The bottom screenshot.

[myokeeh]

@bgavrilMS are you able to reproduce or confirm this somehow?

[bgavrilMS]

Yes, I can repro. I'll update the steps.

[myokeeh]

Do we have any updates on this?

[bgavrilMS]

This will need our friends from WAM to take a look. App doesn't have any control over those windows.

[MSamWils]

Hi @myokeeh, it's by design that the WAM windows (the bottom screenshot) stays open even the underlayer application got terminated. It's because that WAM windows is running in a different process.

[myokeeh]

@MSamWils, can you offer suggestions on how we can address this UX issue somehow?

[myokeeh]

@MSamWils @bgavrilMS I just happened to see this. I don't want to add to this problem: https://twitter.com/marcgravell/status/1656208913706909701?s=46&t=Tpb1beI0_8d1EL5lz_inPg

[bgavrilMS]

Thx for pointing out the tweet @myokeeh - CC @localden @MSamWils @alextok

Ultimately, the vision is that apps should simply not prompt in 90% of the cases. The majority of users want to just silently login with the Windows account and in some small percentage of cases they may want to use a different account, in which case the app should prompt. So the only reason to prompt is:

• if consent or MFA is needed
• if user is not happy being logged in with Windows account

We are still in the process of updating our samples to showcase this pattern better, I wrote a simpler version here https://github.com/bgavrilMS/MSAL-SingleAccount-SSO/tree/master/SSO

Of course, the problems raised here are legitimate and prompting is unavoidable in modern auth, so thanks for raising the visibility.

[MSamWils]

Hi @myokeeh , the WAM UX should be parented to the application where user won't be able to interact with unless the WAM dialog is resolved. If user can interact with the application while the WAM dialog is shown, this will be a bug that we and the application developers needed to investigate. If the application closed because user explicitly terminated it (e.g. from task manager), this will be by design since WAM do not know the state of the calling application.

Regarding for the tweet, we offer a custom design on the sign in page such that application or company can customize it. Please refer to here if your company are interested in it: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/how-to-customize-branding

[myokeeh]

@MSamWils, I pointed out the tweet to show that people don't like to encounter "disconnected" sign pages/windows that have lost or no context. In fact, it heavily erodes confidence in the system. I did not point it out for the customization.

It's hard for me to accept that the experience that I had with UWP apps is better in this regard than what is being pushed now (WinUI3 / WindowsAppSDK) by Microsoft.

For the case that the app crashes (not by user meddling with the Task Manager), why is it accepted as "by design" that the WAM window stay open? The authentication is useless at that point. Doesn't it or Windows monitor the calling app for relevance?

[myokeeh]

@bgavrilMS, I'm also realizing that perhaps because of this separation, the app doesn't have the ability to know if/when the authentication window (WAM) is closed (top right X button). Is that right?

[localden]

I also want to call out that there is a bit of an updated version of the WAM dialog that we use by default in MSAL.NET, the Account Picker, as @bgavrilMS called it out earlier:

Said dialog can attach some extra information, like custom title data:

@bgavrilMS - what's the logic in showing Account Picker vs. legacy WAM windows?

[localden]

I can repro the orphaned account picker scenario, though. Even better - I can't continue in it in any capacity, I can only close it :)

[bgavrilMS]

@localden - the account picker is a windows component separate from WAM. It's official name is Accounts Settings Pane. It is owned by Windows. It is required when combining AAD and MSA accounts.

If MSAL knows we deal only with "work and school" accounts, then it bypasses this picker and goes directly to WAM's AAD plugin, which behaves better in scenarios where you have a login hint etc.

[myokeeh]

Any updates?

[myokeeh]

I just picked up my effort to check out the current state of things and it's disappointing this is still an issue.

[bgavrilMS]

I believe this to have been fixed in latest version of MSAL - 4.61 +

[myokeeh]

@bgavrilMS I just tested it and Microsoft.Identity.Client.Broker 4.61.2 still allows the window to be orphaned.

[bgavrilMS]

Ok, keeping this open. Are you testing with a console app (and which kind - Terminal ?) or with WinUI app?

[myokeeh]

@bgavrilMS WinappSDK 1.6 expermintal1, WinUI3 app.