[Feature Request] Static cache auto-cleanup

[bgavrilMS]

MSAL client type

Confidential

Problem statement

With the introduction of new features such as FMI, more and more access tokens are scoped by additional parameters. This puts pressure on MSAL's static cache.

A simple solution to deal with this is to walk through the static cache and remove expired access tokens. This should only be done when the static cache is used. Something like:

• if there are more than N tokens in the cache (say N=10000)
• lock the cache
• remove expired tokens
• unlock the cache

Alternatively, we can take a dependency (direct or via source code copy) on MemoryCache to replace our static cache. This can easily be done for S2S, where the cache key is known upfront.

Proposed solution

No response

Alternatives

No response

[github-actions]

Here are some similar issues that might help you. Please check if they can solve your problem.

• [Feature Request] In-memory shared cache cache in MSAL (like ADAL), with good performance #2849
• [Feature Request] MSAL internal cache eviction  #3020
• [Feature Request] Add cache eviction to MSAL's internal memory token cache #2645
• [Feature Request] Improve AcquireToken handling for Confidential client flows for expired secrets #1709
• [Feature Request] Need a method to Clear App Token Cache for Confidential Client #4854

---

Possible solution (Extracted from existing issue, might be incorrect; please verify carefully)

Solution 1:

MSAL internal cache eviction is not planned, too complex to build and we have a solution based on MemoryCache.

Reference:

• [Feature Request] MSAL internal cache eviction  #3020 (comment)

Solution 2:

A more general approach, allowing us to move to use Wilson's Event based LRU cache which can add eviction policies. Example: appBuilder.WithMemoryCache(MemoryCacheOptions) where MemoryCacheOptions can include options like MaxNumberOfItems, Expiration, and Static.

Reference:

• [Feature Request] In-memory shared cache cache in MSAL (like ADAL), with good performance #2849 (comment)
• [Feature Request] In-memory shared cache cache in MSAL (like ADAL), with good performance #2849 (comment)

Powered by issue-sentinel

[AmarYasser1]

Hi @bgavrilMS and MSAL team, I'd like to contribute to this feature request and propose a minimal, threshold-based approach for cleaning up expired access tokens from the static in-memory cache.

My Design Proposal: Static Cache Auto-cleanup (Threshold-based)

Approach Overview

Implement a lightweight cleanup pass that removes expired access tokens only when the static cache size exceeds a defined threshold. The goal is to reduce cache pressure while preserving current behavior and performance characteristics.

This approach:

• Requires minimal code changes
• Preserves backward compatibility
• Introduces no new dependencies
• Reuses the existing in-memory cache infrastructure

Implementation Details

1. Cache Options
   Add a new option in CacheOptions.cs:

/// <summary>
/// Default threshold for triggering expired token cleanup.
/// </summary>
public const int DefaultExpiredTokensCleanupThreshold = 10000;

/// <summary>
/// Maximum number of tokens allowed in the static cache before triggering
/// a cleanup of expired access tokens. Default is 10,000. Set to 0 to disable.
/// </summary>
public int ExpiredTokensCleanupThreshold { get; set; } = DefaultExpiredTokensCleanupThreshold;

This option is intended primarily as an internal safeguard rather than a frequently tuned setting.

2. Cleanup Trigger
   In InMemoryPartitionedAppTokenCacheAccessor.SaveAccessToken():

   • After saving a token, check if the total cache entry count exceeds the threshold
   • If exceeded, synchronously trigger a cleanup pass

3. Cleanup Logic
   Add a RemoveExpiredTokens() method that:

   • Iterates through all cache partitions
   • Removes access tokens where IsExpiredWithBuffer() returns true
   • Uses existing locking/thread-safety mechanisms
   • Avoids background threads or timers

Open Questions

Is a default threshold of 10,000 acceptable?

Is limiting the initial scope to AppTokenCache preferred, with UserTokenCache evaluated separately?

Does a synchronous, threshold-triggered cleanup align with MSAL design expectations?

Looking forward to your feedback before proceeding with implementation.