`AspNet.Security.OAuth.Apple` doesn't set cache entry's size

[yasmoradi]

When configuring IMemoryCache in NET apps, it is a best practice to set a SizeLimit to prevent unbounded memory growth and reduce Garbage Collector (GC) pressure. High memory consumption without limits can lead to frequent Gen 2 collections, increasing latency and potentially causing OutOfMemoryException.

However, when a SizeLimit is defined on the cache, every cache entry must have a Size specified. Currently, the DefaultAppleClientSecretGenerator in AspNet.Security.OAuth.Apple generates and caches the client secret without setting the Size property. This causes issues in environments where cache size constraints are enforced.

Current Behavior

The DefaultAppleClientSecretGenerator uses GetOrCreateAsync without providing MemoryCacheEntryOptions that include a Size.

var clientSecret = await cache.GetOrCreateAsync(key, async (entry) =>
{
    try
    {
        (var clientSecret, entry.AbsoluteExpiration) = await GenerateNewSecretAsync(context);
        return clientSecret;
    }
    catch (Exception ex)
    {
        Log.ClientSecretGenerationFailed(logger, ex, context.Scheme.Name);
        throw;
    }
});

Proposed Changes

Specify a default Size (e.g., 1) for the cache entry to ensure compatibility with size-limited memory caches.

var clientSecret = await cache.GetOrCreateAsync(key, async (entry) =>
{
    try
    {
        (var clientSecret, entry.AbsoluteExpiration) = await GenerateNewSecretAsync(context);
        return clientSecret;
    }
    catch (Exception ex)
    {
        Log.ClientSecretGenerationFailed(logger, ex, context.Scheme.Name);
        throw;
    }
}, new MemoryCacheEntryOptions { Size = 1 });

Impact

This change ensures that users who configure services.AddMemoryCache(options => options.SizeLimit = ...) can use the Apple authentication provider without runtime errors related to missing cache entry sizes.

[kevinchalet]

It's worth noting that the size isn't a standardized concept: pretty much every producer uses its own logic to compute the size of an entry (even in .NET/ASP.NET Core itself, things are wildly inconsistent): enabling the size limit on the shared/global IMemoryCache - where entries all have a different size computation logic - will generally lead to a mediocre result, at best 😄

Not saying we shouldn't set a size on our side, but just that no great result should be expected from the size limit mechanism when sharing a global cache instance.

[kevinchalet]

BTW, the official documentation strongly discourages configuring a size limit on the shared cache: https://learn.microsoft.com/en-us/aspnet/core/performance/caching/memory?view=aspnetcore-10.0#use-imemorycache

[yasmoradi]

Thanks for paying attention, really appreciate it.