[Bug] MSAL Library not clearing the user access token from the iOS keychain upon calling RemoveAsync

[cweeding1]

Library version used

4.77.1

.NET version

9.0

Scenario

PublicClient - mobile app

Is this a new or an existing app?

The app is in production, and I have upgraded to a new version of MSAL

Issue description and reproduction steps

Framework: .NET MAUI
.NET 9.0
iOS 13.3.1

Problem Summary:
In a .NET MAUI iOS application, calling RemoveAsync() on an account does not properly remove all associated tokens from the iOS keychain. While the method executes without error and GetAccountsAsync() confirms the account has been removed from MSAL's cache, cached authentication tokens and SSO state remain in the keychain. This prevents users from properly signing out or switching accounts, and allows subsequent authentication attempts to bypass Multi-Factor Authentication (MFA) requirements.

Prerequisites

1. Azure tenant configured with:

• Valid Client ID and Tenant ID
• App registration with appropriate redirect URIs
• Conditional Access Policy requiring MFA

2. .NET MAUI application with MSAL.NET NuGet package installed
3. Physical iOS device. Simulator will not work since you are not able to install a broker
4. Entitlements.plist configured with keychain access groups:

<key>keychain-access-groups</key>
<array>
    <string>$(AppIdentifierPrefix)com.microsoft.adalcache</string>
</array>

5. Microsoft Authenticator setup as the broker application

Reproduction Steps

1. Launch the application and call AcquireTokenInteractive after building the Public Client Application to initiate the authentication flow.
2. Complete the MFA workflow by entering email, password, and approving the push notification that is spawned from the broker application.
3. Verify that account is cached by using something like

var accounts = await _pca.GetAccountsAsync();

4. Remove account using the RemoveAsync method

var accounts = await publicClientApp.GetAccountsAsync();
foreach (var account in accounts)
{
    await publicClientApp.RemoveAsync(account);
}

5. call AcquireTokenInteractive again to start a new authentication flow. Here you will notice the following

• the users account (email) is still stored on the Microsoft Authenticator application. This is not as big of a deal as they will still need to enter a password
• upon entering the password, the push notification from the Microsoft Authenticator application does not spawn and instead the existing token that is stored in the keychain is refreshed.

This can all be confirmed by looking at the token properties that are returned from the AcquireTokenInteractive method.

---

User should be required to complete the full authentication flow:

Manually enter email address (no pre-population)
Enter password
Complete MFA challenge (approve push notification)

A completely new access token should be issued
The authentication experience should be identical to first-time sign-in

Actual Behavior:

The user's email address is pre-populated in the Microsoft sign-in interface
After entering password, the MFA challenge is completely bypassed - no push notification is sent
Authentication completes successfully without MFA approval
The AuthenticationResult shows:

Token is refreshed/reused from the keychain rather than a new token being issued
Token metadata indicates existing token was silently renewed

Despite RemoveAsync() reporting success and GetAccountsAsync() returning no accounts, the underlying tokens remain in the iOS keychain and are being used for silent authentication

Relevant code snippets

<key>keychain-access-groups</key>
<array>
    <string>$(AppIdentifierPrefix)com.microsoft.adalcache</string>
</array>



var accounts = await _pca.GetAccountsAsync();



var accounts = await publicClientApp.GetAccountsAsync();
foreach (var account in accounts)
{
    await publicClientApp.RemoveAsync(account);
}

Expected behavior

Expected Behavior:

User should be required to complete full authentication flow including:

Manual email entry
Password entry
MFA approval (push notification or other configured method)

A completely new token should be issued

Actual Behavior:

User email address remains pre-populated in the Microsoft sign-in interface
After entering password, MFA challenge is bypassed
Authentication completes without MFA approval
Examination of the AuthenticationResult reveals:

The existing token was refreshed/reused rather than a new token being issued
Token timestamps indicate the original token was extended, not replaced

User credentials and SSO state remain in the iOS keychain despite RemoveAsync() being called

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

No response

[github-actions]

This issue is related to security. Please pay attention.

Powered by issue-sentinel

[Quaybe]

Have you tried Android by chance? I believe I am also having this issue on my Android build, as well as iOS. Using Microsoft.Identity.Client 4.77.1 with .NET 9 in a .NET MAUI project that targets Android, iOS, and Windows.

I call RemoveAsync(account), and have confirmed GetAccountsAsync shows nothing. However, the next time I go to log in, the user I just signed out still shows signed in. I tap on the name and it signs right in, no MFA at all, just like you said.

This doesn't seem like it was an issue just a week or so ago? I could swear I've tested signing out and it has worked properly in the last week or two.

[cweeding1]

@Quaybe The android side of things appears to be working fine, but I will check again and get back to you. This is a project I am currently working on, so I am not able to say if it was previously working. I just started on the iOS side of things last week and it has been a problem since then.

Edit
This is still working correctly on Android. Calling RemoveAsync clears out the accounts and the tokens on the device. Then upon calling the AcquireTokenInteractive again the user is prompted to select an account (the accounts dont get removed from the authenticator application) and to enter their password. Upon entering the password, a MFA notification is spawned that they have to approve in order to get a new token.

[cweeding1]

@Quaybe would you also be able to look at the Azure sign in logs for you users that are having this problem? I have a conditional access policy setup to require MFA for users every time. It appears that when the cached token is used, that the MFA policy is not applied.

For my android users I can see that the conditional access policy is applied and that they approved a mobile notification for MFA

but for iOS users

Despite both users being in the same application group with the same conditional access policy, it seems that android is the only one that enforcing the MFA due to the token caching issue on iOS

[Quaybe]

Hey @cweeding1 , sorry to muddy the waters, here. I believe my issue is related to Okta browser sessions/cookies, since we federate to Okta. Again, sorry to distract.

[cweeding1]

No problem @Quaybe when you get that fixed would you be able to test the token caching again on Android and iOS to see if the issue persists