[Bug] GetAccountsAsync returns more accounts than it shows in Windows Accounts settings

[aries-zhang]

trafficstars

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

Platform .Net Framework 4.8, Windows 11

What authentication flow has the issue?

• Desktop / Mobile
  • [x] Interactive (broker)
  • [ ] Interactive (embedded or system browser)
  • [ ] Integrated Windows Authentication
  • [ ] Username / Password
  • [ ] Device code (browserless)
• Web app
  • [ ] Authorization code
  • [ ] On-Behalf-Of
• Daemon app
  • [ ] Client credentials (service-to-service calls)

Other?

Is this a new or existing app? a. The app is in production, and I have upgraded to a new version of MSAL.

The app is currently using MSAL .Net 4.45.0, we found this issue when we are upgrading it to 4.54.1.

Repro

var client = PublicClientApplicationBuilder.Create("my-client-id")
    .WithAuthority("https://login.microsoftonline.com/consumers")
    .WithBroker(new BrokerOptions(BrokerOptions.OperatingSystems.Windows)
    {
        ListOperatingSystemAccounts = true
    })
    .WithExperimentalFeatures()
    .WithLogging(logger)
    .Build();

IEnumerable<IAccount> accounts = await client.GetAccountsAsync().ConfigureAwait(false);

In my test, there are 2 accounts in Windows settings, the main OS account is an AAD, and the second account is a personal account.

The above code returns 3 accounts. The last one outlined is another personal account I used to have but now removed from Windows settings (Emails & accounts).

And in our case when there are multiple MSA accounts, we show the account selector view for the user to choose which account they would like to login, however, the outlined account in the previous screenshot does not show in the login pop-up. This is consistent with what's shown in Windows settings.

Actual behavior The list returned by GetAccountsAsync has more accounts than what is shown in Windows Settings -> Accounts -> Email & accounts.

Expected behavior Windows Settings -> Accounts -> Email & accounts should be keeping all the currently logged-in accounts and should be consistent with what IPublicClientApplication.GetAccountsAsync returns when the client is configured to list operation system accounts.

[gladjohn]

@MSamWils please let me know what information you need to debug this

[aries-zhang]

Hi @MSamWils @gladjohn wondering if this is in any release plan yet?

[bgavrilMS]

I don't think this was root caused yet @aries-zhang, but it does seem like a rare occurance?

The repo would be in the lines of?

• user adds Personal account A1 and A2 to Windows
• app lists all accounts -> A1 and A2
• user removes Personal account A2 from Windows
• app lists all accounts

Expected: A1 Actual: A1 and A2

I suspect this is because msal runtime stores metadata about account A2 in its cache, it doesn't actually discover the accounts every time (discovery is quite expensive operation, involving HTTP requests to AAD.

[aries-zhang]

I don't have data about the occurrence rate of this issue, but it seems to be reproduceable on 2 of my test machines (1 laptop and 1 VM both with AAD as OS account + MSAs for "Emails & accounts").

It does seem to be more relating to cached accounts since it gets correct accounts once MSAL cache is removed under ~\AppData\Local\Microsoft\IdentityCache\1\UD, but goes back when an account is logged-in and removed again.

[localden]

How common of a user scenario is this @aries-zhang? As in - do you expect your users to frequently remove accounts and log out?

[aries-zhang]

Hi @localden, sorry we currently don't have any data to tell how frequently our users change accounts, but when this issue happens, it could confuse our users because they might be prompt to login with an account they have removed (could potentially be any account that has previously logged on to the device). Wondering if there is another way to get the correct accounts on a device except GetAccountsAsync, so that we might be able to get some visibility about the occurrence rate of this issue?

[ashok672]

@aries-zhang - the account cache in MSALRuntime layer comes from all apps. This is by design. MSALRuntime will likely have more accounts than in WAM in some cases. And there are various reasons this could happen. For example, an app in the system using Embedded browser flow and new user logs in. This flow will not populate that new user account in WAM.