[Bug] RemoveAsync doesn't always work if PublicClientApplicationBuilder is using broker

[azchohfi]

trafficstars

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

Platform .NET 6

What authentication flow has the issue?

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

Is this a new or existing app? This is a new app or experiment.

Repro Trying to use the method described here: https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-clear-token-cache results in an infinite loop if there is an account the PublicClientApplicationBuilder was created using the WithBroker() method.

            _app = PublicClientApplicationBuilder
                .Create(ClientId)
                .WithBroker()
...
            authenticationResult = await _app.AcquireTokenInteractive(scopes).ExecuteAsync();
...

            accounts = (await _app.GetAccountsAsync()).ToList();

            // clear the cache
            while (accounts.Any())
            {
                await _app.RemoveAsync(accounts.First());
                accounts = (await _app.GetAccountsAsync()).ToList();
            }

Expected behavior No infinite loop, and cache is actually cleared, or at least a workaround for the broker scenario that actually clears the cache.

Actual behavior Infinite loop or cache is not properly cleared.

Possible solution No idea. I've tried creating another PublicClientApplicationBuilder without the broker and then looping through the accounts to delete them, but using the broker will keep that account as if was not deleted, so the cache is not really cleared.

[pmaytak]

Do you happen to set ListWindowsWorkAndSchoolAccounts to true? There was a similar issue: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/2696

Does this happen for all account types, like if you login with Operating System account vs login with an account only into the app itself?

[azchohfi]

I did have ListWindowsWorkAndSchoolAccounts set to on, but I've tried to turn it off and it still doesn't work, and yes, the specific account that won't go away is a "*.onmicrosoft.com" (work account) account, which is on the "Accounts by other apps" settings, so yes, this seems similar to #2696.

Wouldn't it make sense for the broker not force those accounts if I want to specifically remove them? It should have a copy of those accounts in the cache that I've specified.

The problem I'm facing is that this behavior is keeping me from being able to completely sign the user of my app. The documentation for GetAccountsAsync says: "Returns all the available accounts in the user token cache for the application.", so I was assuming that this cache was specifically for my app, not the cache of all the users in the OS. Even if I delete my MsalCacheHelper file, the user is still there.

[bgavrilMS]

@azchohfi - can you please delete the cache file and try again with the new broker? https://aka.ms/msal-net-wam from Microsoft.Identity.Client.Broker? We are removing the old implementation in a few weeks.

ListWindowsWorkAndSchoolAccounts isn't implemented in the new broker, but it will be soon. Do you really need this functionality? Most applications would want to login the default OS user only. Then account removal behaves normally.

If you do ListWindowsWorkAndSchoolAccounts, then MSAL returns a combination of WIndows accounts + cache accounts. You cannot remove Windows accounts. Toggling ListWindowsWorkAndSchoolAccounts is not a supported scenario.