IdentityServer 7.4.x: Exponential claim duplication in server-side sessions with ASP.NET Identity

[CHaerem]

Problem

After upgrading from Duende.IdentityServer 7.3.2 to 7.4.x, server-side sessions grow exponentially. Claims are duplicated on each security stamp validation, following a 2^n growth pattern. Sessions can reach 15+ MB and cause OutOfMemoryException.

Reproduction Steps

1. Configure IdentityServer with server-side sessions and ASP.NET Identity:

   services.AddIdentityServer()
       .AddServerSideSessions()
       .AddAspNetIdentity<IdentityUser>();

2. Log in via an external identity provider (Azure AD, OIDC, etc.)

3. Make multiple authenticated requests (each triggers security stamp validation with default ValidationInterval)

4. Check session size:

   SELECT [Key], LEN(Data) / 1024 as SizeKB
   FROM ServerSideSessions
   ORDER BY LEN(Data) DESC;

Expected Behavior

Session size remains stable (~2-5 KB).

Actual Behavior

Session size doubles with each security stamp validation:

Validations | Claims per type | Session Size -- | -- | -- 1 | 1 | ~2 KB 5 | 16 | ~30 KB 10 | 512 | ~1 MB 15 | 32,768 | ~15 MB

Workaround

Downgrade to 7.3.2.

Environment

• Duende.IdentityServer.AspNetIdentity 7.4.0 / 7.4.1 / 7.4.2
• .NET 10.0
• SQL Server with Entity Framework
• Server-side sessions enabled

[wcabus]

Thanks for raising this issue! I can confirm that this is indeed a bug, causing the server-side session to grow as stated, eventually causing either an OutOfMemoryException or ArgumentException while trying to (de)serialize the session's payload. Most likely this bug was introduced by PR 2213

[wcabus]

@CHaerem We’ve released a new version 7.4.3 which fixes this problem.

[ldellisola]

Is it possible that this bug is also the reason for an abnormal increase in the size of the PersistedGrants table?

We upgraded to 7.4.x last Thursday and our DB has been increasing in space multiple times:

We didn't have token cleanup enabled, so the DB was already quite big (~25GB) but it has been growing to 80+ GB this week.

Since then we have enabled token cleanup and manually deleted all the expired entries (taking the table from 2.7 million entries to ~100K) but the DB keeps increasing in size.

For some context, the Data field in PersistedGrants is around 40MB per row now while the Data field in ServerSideSessions is around 20 to 30 MB.

SELECT TOP 4
    t.name AS TableName,
    p.rows AS [RowCount],
    CAST(ROUND(SUM(a.total_pages) * 8.0 / 1024 / 1024, 3) AS DECIMAL(18,3)) AS TotalSizeGB,
    CAST(ROUND(SUM(a.used_pages) * 8.0 / 1024 / 1024, 3) AS DECIMAL(18,3)) AS UsedSizeGB
FROM  sys.tables t
INNER JOIN sys.schemas s ON t.schema_id = s.schema_id
INNER JOIN sys.indexes i ON t.object_id = i.object_id
INNER JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a ON p.partition_id = a.container_id
WHERE t.is_ms_shipped = 0 AND i.object_id > 255
GROUP BY  s.name, t.name, p.rows
ORDER BY TotalSizeGB DESC, [RowCount] DESC;

TableName	RowCount	TotalSizeGB	UsedSizeGB
PersistedGrants	123407	77.894	76.243
ServerSideSessions	21515	3.256	3.224
PushedAuthorizationRequests	386086	1.128	1.113
AspNetUsers	81116	0.099	0.098

[wcabus]

This could indeed be related. Several of the persisted grant models (refresh token, authorization code to name two) include the current ClaimsPrincipal subject. This ClaimsPrincipal is being serialized into the persisted grant, including the potentially duplicated claims.

v7.4.3 should also fix this issue.