[Bug] Perf degradation of AcquireTokenForClient due to default partitioned cache

Is your feature request related to a problem? Please describe. Starting in MSAL 4.30, there’s a default in-memory partitioned cache for confidential client applications. For each cache operation, the data is serialized/deserialiazed, which causes a performance hit. Seems to be a bigger issue for apps that have single-tenant partitions with many resources per tenant.

Possible solutions

1. Partition the internal cache.

• Create PartitionedInMemoryTokenCacheAccessor that implements ITokenCacheAccessor and is similar to InMemoryTokenCacheAccessor except that the token dictionaries are partitioned by tenant id.
• Add overloaded GetAllX methods that accept a tenant parameter.
• In TokenCache, for confidential client app, set the accessor to the partitioned one.

1. Explore having a smaller partition key; currently it’s client ID + tenant ID.

• In SuggestedWebCacheKeyFactory, add requestParams.Scope to the app cache key string.

1. When searching through the internal cache, find token by key first then go through filters.

• In TokenCache.ITokenCacheInternal.FindAccessTokenAsync, call _accessor.GetAccessToken and pass a created MsalAccessTokenCacheKey. Some [additional filtering] might still need to be done.

Also add performance tests to compare before and after change. (Testing scenario should include single- and multi-tenant cases with many resources.)

[bgavrilMS]

Let’s treat this as a performance regression. Since before MSAL 4.30, AcquireTokenForClient would not use any JSON operation, but afterwards it does, leading to increased number of allocations.

[jmprieur]

nom @rymeskar the RT for OBO token is reusable for 90 days (provided, today you give the userassertion, which might have expired, but is used as a key to the cache). @pmaytak is actually improving the experience for OBO tokens used in long running processes: https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/pull/2820