@jennyf19,@GeoK,@pmaytak
We need to discuss the impact on MISE of this PR: the cache would no longer be static when customer decide InMemoryCache, but it would grow and would require eviction policies.

Potential Issues for Adopting Services

1. Cache Behavior Change
   Before: MsalMemoryTokenCacheProvider used MSAL's static shared cache (CacheOptions.EnableSharedCacheOptions)
   After: Uses MemoryCache (ASP.NET Core's IMemoryCache) for token storage
   Impact: Services using in-memory caching may experience different cache isolation characteristics. The static cache was shared across all app instances in the same process, while IMemoryCache provides better scoped isolation.

2. Memory Management
   Concern: IMemoryCache has different eviction policies compared to MSAL's static cache
   Potential Issue: In high-load scenarios, tokens might be evicted from cache more aggressively, leading to more token acquisitions from the identity provider
   Recommendation: Services should monitor token acquisition patterns and potentially configure MemoryCacheOptions appropriately

3. Multi-Tenant Scenarios
   Before: The shared static cache could cause issues with cache key collisions across tenants
   After: Better isolation, but services need to ensure their cache configuration supports their multi-tenancy model
   Impact: This is likely a positive change for multi-tenant apps, but services should verify tenant isolation works as expected

4. Performance
   the In memory cache would be 10x slower than the static cache.@bgavrilMS : do you confirm

Agree with@jmprieur, it is a large behavioral change, can this be an opt-in behavior?

We need to discuss the impact on MISE of this PR: the cache would no longer be static when customer decide InMemoryCache, but it would grow and would require eviction policies.

Without eviction policies, we're just trading "static dictionary with predictable growth" for "MemoryCache with unpredictable growth...not an improvement, just a different problem

MSAL static cache

Pros: fast
Cons: no eviction policies and no way to set them

MemoryCache

Pros: app developer can set eviction policies
Cons: slower

If we do opt-in, how would that setting look like?

@bgavrilMS : the recommendation from the MISE team is to add a new boolean in the MicrosoftIdentityApplicationOptions or one of its base classes to specify if to use the static cache or not. An opt-in to use an evictable but slower in-memory cache, making this PR no longer a breaking change.

+1 to making this an opt-in change via options. In my experience, different users value different things (cache size vs speed). Setting and changing the default will make someone unhappy. Another point is that when we make big changes like this, even in major versions, it reduces the SDK maintainability a bit. For example, when users have issues, it'll add time to figure out which SDK version has which cache and such. So maybe for now if we keep static cache as default but make it clear on how to change it if size becomes an issue.