RemoveAsync not working after caching tokens from OBO flow [Bug]

Logs and Network traces Without logs or traces, it is unlikely that the team can investigate your issue. Capturing logs and network traces is described at https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/logging

Which Version of MSAL are you using ? Microsoft.Identity.Client 4.25.0

Platform .Net Framework 4.7.2

What authentication flow has the issue?

Desktop / Mobile Interactive Integrated Windows Auth Username Password Device code flow (browserless) Web App Authorization code OBO Daemon App Service to Service calls Other? - please describe;

This is when adding msal to an existing app. Msal is not in production on the app currently.

Repro

var your = (code) => here;

Expected behavior When calling ConfidentialClientApplication.RemoveAsync, the tokens should be removed from the cache

Actual behavior If I pass the IAccount as below I get the following error

var authResult = await AquireTokenOnBehalfOf(scopes, jwt);

await ConfidentialClientApplication.RemoveAsync(authResult.Account);

‘Response status code does not indicate success: NotFound (404); Substatus: 0; ActivityId: 65f56124-de0e-47d8-8150-0a530559e161; Reason: ({ “Errors”: [ “Resource Not Found. Learn more: https://aka.ms/cosmosdb-tsg-not-found” ] });’

Possible Solution

Additional context/ Logs / Screenshots Using CosmosCache More context from my previous issue here

[jmprieur]

Thanks for the explanation, @SirElTomato So I understand that you’d want RemoveAccount to remove all the tokens related to the user, not the token issused from the token used to call your web API.

@henrik-me @jennyf19 @bgavrilMS interesting scenario which affects the partition algorithm used for the cache. OBO uses incoming the token hash, and that’s what is used as a cache key, the user is not even part of the cache key.

[bgavrilMS]

This is by design, it is suggested to add an eviction policy. I added a few more comments our wiki related to this: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/on-behalf-of#cache-eviction-for-long-running-obo-processes:

Cache eviction for long-running OBO processes
It is strongly recommended to use a distributed persisted cache in a web api scenario. Since these APIs store the refresh token, MSAL will not suggest an expiration, as they can be used over and over again.

It is recommended that you set L1 and L2 eviction policies manually, for example a max size for the L1 cache and a sliding expiration for the L2.

Removing accounts
MSAL cannot perform account removal for OBO when using L2 caches. It is recommended to use eviction policies. If immediate removal is needed, delete the L2 cache node associated with the sessionKey.

CC @jmprieur for a quick review.