[Bug] UWP Interactive Auth Window Popup Freezes

[hjohnson12]

Logs and network traces N/A

Which version of MSAL.NET are you using? MSAL.NET 4.40.0

Platform UWP

What authentication flow has the issue?

• Desktop / Mobile
  • [x] Interactive
  • [ ] Integrated Windows Authentication
  • [ ] Username Password
  • [ ] Device code flow (browserless)
• Web app
  • [ ] Authorization code
  • [ ] On-Behalf-Of
• Daemon app
  • [ ] Service to Service calls

Other?

Is this a new or existing app? New app, as well as an existing application in production upgraded to a new version of MSAL

Repro The issue occurs both in an existing application using the steps from the UWP tutorial as well as the tutorial example itself I just retried from scratch. Located here: https://docs.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-windows-uwp Link to download the tutorial sample: https://github.com/Azure-Samples/active-directory-dotnet-native-uwp-v2/archive/msal3x.zip

Expected behavior Application authenticates accordingly and closes the interactive prompt

Actual behavior The interactive UI prompt freezes and doesn't finish authentication.

Possible solution N/A

Additional context / logs / screenshots / links to code Upon signing in on my existing application, it freezes at the screen below and has the blue dot at the top right and just keeps flashing / not proceeding. Additionally in the tutorial it does the same thing once I get to accepting permissions or trying to sign in again after force closing MicrosoftAuthHost. If I force cancel the AuthHost, sometimes it'll finish the authentication but that's the only way it seems to work.

[bgavrilMS]

@trwalke - can you reproduce this? @hjohnson12 - it's better to use a different control in UWP apps - WAM. See https://aka.ms/msal-net-wam . Can you try with WAM? It involves registering a new redirect URI and making sure that you call AcquireTokenInteractive from UI thread.

We are planning on deprecating the AuthHost, but it will involve bumping the major version of the library

[bgavrilMS]

I think this is cause by a Windows update problem, since nothing else really changed.

There are 2 ways to go to bring this issue to a conclusion:

1. We need some operational logs for the WAB (AuthHost) account control. See https://docs.microsoft.com/en-us/windows/win32/secauthn/web-authentication-problems on how to get logs. Also please specify the version of Windows and if this alyways happens etc.
2. Alternatively, move away from this old mechanism and use WAM. This is the way forward and we want to make it default on both UWP and win32. See https://aka.ms/msal-net-wam

[hjohnson12]

Hey @bgavrilMS , my apologies for the late response! I was actually able to successfully setup the UWP tutorial as well as my existing application using WAM following the link you provided. I also read over the couple examples from https://github.com/Azure-Samples/active-directory-xamarin-native-v2 (in-case any others were curious when reading this).

I did run into an odd error when building in Release mode on my existing application when MSAL.NET 4.40.0 is combined with Microsoft.Graph v4.3.0-4.15.0, although the UWP tutorial I was doing from scratch as a test ran perfectly with all of the Microsoft.Graph versions so its probably something else within my project and unrelated to this issue :)

For the MS AuthHost bug, in-case you want some info if its pertaining to a Windows Update, my build is 19044.1466 on Windows 10 21H2. The WAM setup works great for me though so I'm okay with sticking with that from here on out! It seems to be more smooth running too.

Many thanks!! :)

[bgavrilMS]

Thank you for the update @hjohnson12 ! Let us know if WAM is causing any issues in the long run.

[georgii11]

Hi! Thanks for redirecting me from 3086, @bgavrilMS. I've attached the events I captured while encountering this issue: UnresponsiveAuth.zip From what I can tell it happens for all users and every time when going through the Auth view. On my side as well, if I force close the view, the login will be often finished successfully. My OS is Windows 10 Pro - 19043.1466 (it did also happen on a previous ver, not sure exactly which, but still a recent one). Thanks!

[bgavrilMS]

@georgii11 - I cannot access the zip file. Can you send it by email to bogavril at microsoft com please?

[georgii11]

@bgavrilMS sent with the subject [AzureAD][microsoft-authentication-library-for-dotnet][3109]. Hope it got through.

[bgavrilMS]

Thanks @georgii11 - I received the file. I'm going to ping the Windows team who own this control.

[LDS2020]

I have been working on this same issue for the last week although it is only happening on Windows 11 (22000.466) with personal accounts. i.e. does not happen with Work or School accounts on Win11 or with either type of account on Win 10 (19042.1466) or Xbox.

I will test it with WAM but in the meantime you may want to check out this repo I created.

Which version of MSAL.NET are you using? MSAL.NET 4.39.0

[juanmalm]

Same issue here. Happening randomly on Windows 10 with any kind of account. Using MSAL.NET 4.40.0.

[surya-sk]

Same issue here, and using WAM the app just crashes after selecting an account. This only seems to be happening on Windows 11. I've tested on two Windows 11 devices with MS accounts with gmail.com addresses and on two Windows 10 devices with outlook accounts. Not sure if this is an issue with non-Outlook accounts or Windows 11

[jeevanbalanmanoj]

@LDS2020 @juanmalm @surya-sk are you facing this issue on Azure AD? If so please move to WAM as @bgavrilMS recommended. Here is the guide on it https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/wam Do let us know if you are on B2C and not Azure AD

[LDS2020]

@jeevanbalanmanoj Yes, I am using Azure AD. I have not migrated my Windows Store apps yet and am still testing with the sample app I mentioned above.

Good news is that using WAM I can successfully login interactively and grant consent the first time (without freezing) for both Personal and WorkAndSchool accounts on Win11, which I was not able to do using AuthHost. Have not tested Win10 yet.

Bad news:

• on subsequent silent login attempts I get an ropc_not_supported_for_msa exception for Personal accounts and an integrated_windows_auth_not_supported_managed_user exception on standard Office 365 accounts.
• if I logout (RemoveAsync) of either type of account and try to log back in again (which forces an interactive attempt) it merely asks to select the account and grants a token without prompting for a password (almost like SSO), which defeats the purpose of logging out. I need to figure how to expire all tokens.
• on Xbox no dialog appears (in Edge or native) to allow the user to interactively enter their credentials.

Bottom line is that I need to:

• resolve these issues
• figure out how to force a mandatory upgrade of my apps in the Windows store for all users before I can consider WAM to be a viable workaround.

[surya-sk]

@jeevanbalanmanoj I did try WAM but it doesn't seem to work either. The app just crashes after selecting account. I'm unable to reproduce the issue on my machine which makes it hard to figure out what's happening

[bgavrilMS]

@LDS2020 - AcquireTokenByUsernamePassword and AcquireTokenByIntegratedWindowsAuth do not use WAM, they still go via MSAL's internal flow. Let's discuss them separately (open GH items) if needed (e.g. Username/Password will never work for MSA accounts btw). I'd recommend you do AcquireTokenSilent(DefaultOSAccount) with WAM instead of AcquireTokenByIntegratedWindowsAuth

SSO is a key value proposition of WAM (and of browsers too). Users who are forced to type-in passwords often start typing them blindly. The user is already logged into the OS, why would they re-login explicitly into your app? In any case, you can configure the sing-in frequency for users if you wish to https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency

I am not familiar with Xbox apps, but I do believe there are specific APIs for it - see https://docs.microsoft.com/en-us/gaming/xbox-live/features/identity/auth/auth-uwp/live-auth-for-uwp-projects

[bgavrilMS]

The cause of this issue seems to be as follows:

• AAD redirects the users to various web pages to collect credentials etc.
• the web auth UWP component does some validation for each of these redirects. In particular, it does not allow pages which are classified as CrossDomain or MixedContent.

The Windows team in charge of the UWP component state they have not made any changes to it recently, so the next step is to investigate if AAD has made any changes to the pages themselves. I will keep the thread posted on any findings.

The guidance to move to WAM still stands, as UWP AuthHost control is being deprecated as is difficult to service.

[LDS2020]

@bgavrilMS

• I switched the first call to AcquireTokenSilent and both of those exceptions have gone away. Thank you.

• I understand what you're saying about the benefits of SSO but neither the MSA or O365 account are the same as the local Windows account. I even rebooted and it still allowed me to login into these accounts without prompting for a password so I'm not sure where it is persisting these credentials?

• Thank you for the link to the Xbox docs but they are for Xbox Live which I am not using. I am simply connecting to Microsoft Graph with MSAL. Ordinarily I would say that I will continue to use AuthHost on Xbox and WAM on everything else, as I never had a freezing issue but if it will be deprecated I am very curious if WAM will be supported before then? This doc indicates it currently is not if WAM is dependent on Windows.Security.Credentials? Approx 45% of my user's sessions in the last 6 months were on Xbox so this would be an issue.

[bgavrilMS]

@LDS2020

• With regards to SSO. There are "SSO artefacts" in a variety of places. The browser has cookies which help SSO. MSAL maintains a token cache (not used too much when WAM is enabled). WAM has access to the OS accounts and maintains their own cache. Generally we recommend that you try to achieve a "1 prompt per user per device" state. Look at Office or Visual Studio - they very rarely prompt.

Note that the browser and the OS belong to the user, not to your app. If a user signs out of your app, you can simply call "app.RemoveAsync(account)" and all artefacts tied to the app will be deleted. AcquireTokenSilent will not work, you'll have to re-login interactively. The fact that the user does not need to enter a password when they do interactive login is not an application concern. Is this not your observed behavior?

• With regards to xbox. WAM allows you to login with "Work and School" accounts (e.g. alice@contoso.com) and with "Personal" accounts (.e.g. bob@outlook.com). This is the same as using MSAL with the browser. Are you saying that you deploy an app to Xbox and WAM doesn't work there? Do you get an exception?

[LDS2020]

@bgavrilMS

• I am sure very smart people who are experts in both UX design and security have thought through the implications of the SSO features so I will accept that is how it works.
• On the Xbox issues, when using WAM it simply stops at AcquireTokenInteractive without an exception. No dialog or screen appears to capture the user's login credentials. I have sent you MSAL log files and screen shots directly for you to look at.

Thank you.

[bgavrilMS]

Thanks @LDS2020 , I'll follow up with the Windows team to better understand the xbox issue.

[bgavrilMS]

Folks, to understand the severity better, can you please chime in with:

• how many users are affected?
• are only Microsoft personal accounts affected ? (i.e. @outlook.com etc.) or both personal accounts and work and school accounts?
• does this issue happen for all users or just for some?
• does the problem reproduce consistently for the affected users?

Thanks!

[BC89]

This is affecting our LOB application for all users with increasing frequency. First reports were in the October timeframe 2021.

[27k1]

This is affecting our LOB application for all users with increasing frequency. First reports were in the October timeframe 2021.

Same here with our LOB app. Started in November with VS 2022 only, now it has recently come with VS2019.

It hangs forever with no exception.

I've just tested tjhis and Microsoft.Graph 4.7.0 and Microsoft.Identity.Client 4.37.0

Works great, so if Microsoft can please fix this quickly to discover which update has caused the issue (only in release mode) I am using x64.

[27k1]

Ok, The issue occurs when the app is installed the first time. I have set up a test app and the issue was introduced in Microsoft.Graph 4.9.0 4.8.0 Works correctly everytime. I am using Microsoft.Identity.Client 4.41.0, so the issue in in Microsoft.Graph 4.9.0 onwards.

Example code below,

```
    try
        {
            authResult = await PublicClientApp.AcquireTokenSilent(_scopes, _userAccount)
                                              .ExecuteAsync()
                                              .ConfigureAwait(false);

            responseModel.UserName = authResult.Account.Username;
        }
        catch (MsalUiRequiredException ex)
        {
            // A MsalUiRequiredException happened on AcquireTokenSilentAsync. This indicates you need to call AcquireTokenAsync to acquire a token
            System.Diagnostics.Debug.WriteLine($"MsalUiRequiredException: {ex.Message}");

            try
            {
                authResult = await PublicClientApp.AcquireTokenInteractive(_scopes)
                                                  .ExecuteAsync()
                                                  .ConfigureAwait(false);

                responseModel.UserName = authResult.Account.Username;
            }
            catch (MsalException)
            {

            }
        }
        catch (Exception ex)
        {
            //await DisplayMessageAsync($"Error Acquiring Token Silently:{System.Environment.NewLine}{ex}");
            return null;
        }

[bgavrilMS]

For tracking purposes, this is the work item opened on Windows team who maintains the WAB control - https://microsoft.visualstudio.com/OS/_workitems/edit/38159713

[bgavrilMS]

No ETA on a fix, but this is being investigated actively by Windows team and AAD service team.

[27k1]

No ETA on a fix, but this is being investigated actively by Windows team and AAD service team.

Excellent.

[bgavrilMS]

From the discussion on the thread, it looks like the consent screen is the one that's blocking. For Work and School users, the tenant admin can pre-consent, thus avoiding this screen. So that's a small workaround for Work and School

[bgavrilMS]

Folks, this issues should have been fixed with an update to AAD. Please let me know if you are still experiencing issues.

The root cause is that the WebAuth control uses some pretty old technologies to inspect the incoming HTML pages, and it classifies the "consent" page as having insecure content and freezes. While this is not true - the content is not insecure - fixing the WebAuth component is not at all trivial (it ships with Windows), so AAD have made some changes to the consent pages to make WebAuth happy.

[27k1]

I can confirm that this issue is fixed in Graph 4.19.0 Many thanks.

[bgavrilMS]

New update on this. The fix went through for Work and School accounts, but the problem persists for Personal accounts. The fix for Personal Accounts will be live in 2-3 weeks.

[georgii11]

Hello! Is this happening again for anyone else? On my side it was fixed for a while, but now the freeze is back. Edit with a few extra details: it doesn't occur with 100% repo now and only on some devices. Details of the operating system on two devices on which it occurred:

• Windows 11 Pro for Workstations 64-bit (10.0, Build 22000) (22000.co_release.210604-1628)
• Windows 10 Pro Education 64-bit (10.0, Build 19044) (19041.vb_release.191206-1406) and for devices on which it didn't:
• Windows 10 Pro 64-bit (10.0, Build 19042) (19041.vb_release.191206-1406)
• Windows 10 Pro 64-bit (10.0, Build 18363) (18362.19h1_release.190318-1202)
• Windows 10 Home 32-bit (10.0, Build 19042) (19041.vb_release.191206-1406)

Thanks!

[premiaware]

Hello i have same issue, the login freeze my UWP App. using this code now work again.

try { authResult = await _identityClientApp.AcquireTokenInteractive(Scopes) .WithPrompt(Microsoft.Identity.Client.Prompt.Consent) .ExecuteAsync() .ConfigureAwait(false); } catch (MsalException msalex) { await DisplayMessageAsync($"Error Acquiring Token:{System.Environment.NewLine}{msalex}"); } ....

[bgavrilMS]

@premiaware - can you share your client Id, redirect uri and scopes and also tell me if you are logging in with a Work & School account or a Personal account?

[premiaware]

ClientId="9204be2f-41fa-4846-b1e7-e7c4b37e6405" private static string[] Scopes = { "User.Read", "Files.ReadWrite", "Files.ReadWrite.AppFolder" }; Personal account i don't set redirect uri adding .WithPrompt(Microsoft.Identity.Client.Prompt.Consent) work now without freeze.

[MusicMan3001]

Hi, this is happening to me too. Sometimes it works, but mostly it hangs.

It only seems to happen with Personal accounts. I haven't gotten it to hang with a Work account.

I can confirm that adding WithPrompt(Microsoft.Identity.Client.Prompt.Consent) seems to fix the issue, but this is not a good user experience.

[bgavrilMS]

I could not repro this when I tried.

The thing to do is:

• try to move to use WAM, see https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-acquire-token-wam
• if you cannot (e.g. you run on xbox), then please raise a support ticket with Azure Active Directory

If someone who can repro the bug can try to capture a Fiddler trace or give me a correlation ID and a timestamp, I can raise an incident with AAD as well.

[MusicMan3001]

If I move to WAM, then I have to change the Redirect URI in AAD, right? That's a problem, because it will affect the current version of the app that is already distributed to users. Can you please explain how to migrate to WAM while maintaining backwards compatibility with the previous URI (https://login.microsoftonline.com/common/oauth2/nativeclient)? Or can I have more than one URI registered so that both the previous one and the new one will work?

[premiaware]

The incomprehensible thing is why it was working before and now you have to apply workaround changes, this thing blocked me 450 clients in one day. In any case, it works for me now by entering WithPrompt(Microsoft.Identity.Client.Prompt.Consent) I'm keeping this for now, I can't spend my life on workarounds

[bgavrilMS]

If I move to WAM, then I have to change the Redirect URI in AAD, right? That's a problem, because it will affect the current version of the app that is already distributed to users. Can you please explain how to migrate to WAM while maintaining backwards compatibility with the previous URI (https://login.microsoftonline.com/common/oauth2/nativeclient)? Or can I have more than one URI registered so that both the previous one and the new one will work?

You don't have to CHANGE the existing redirect URI, you add a new one. Your application supports multiple redirect URIs indeed.

For example Visual Studio application has 3 redirect URIs.

• https://login.microsoftonline.com/common/oauth2/nativeclient
• http://localhost for system webview
• WAM redirect URI

[bgavrilMS]

The incomprehensible thing is why it was working before and now you have to apply workaround changes, this thing blocked me 450 clients in one day. In any case, it works for me now by entering WithPrompt(Microsoft.Identity.Client.Prompt.Consent) I'm keeping this for now, I can't spend my life on workarounds

Adding Consent Prompt is not a good user experience. It'll re-prompt for consent every time. Normally, a user has to provide consent only once.

The problem is caused by the fact that UWP is hard to test and by the fact that Identity organization invests more in WAM. We run UI automation on some web browsers in win32 applications, but have not found a solution for UWP. The "workaround" which I provided is the path forward for increasing the reliability and security of your app.

[premiaware]

Thank's for your support, i have updated all my customers all working ok, not login prompt is required all working as before. at least until the next change when maybe it won't work again. thanks again for the support.

[MusicMan3001]

I can confirm that the WAM solution fixes the problem without requiring the the consent prompt to be forced. It also provides a nicer user experience than the non-WAM solution. Thanks.

[SameerK-MSFT]

It looks like many customers have confirmed that this works for them and there is no activity for 1.5mon. I will close this. Please reopen if this still persists.