Correlation and Nonce cookies

[mbalogh89]

Related: #1133, #1262

Hi,

I'm using an MVC client with Cookie and OpenIdConnect middleware authenticating via an identity provider based on IdentityServer4.
Not new stuff: whenever a new login session starts, a Correlation and a Nonce cookie is created on the client side, which could increase the Request/Response header size. It could be solved with some expiration settings, but I looked forward a better solution.
Before version 2.0.0 I solved my problem subscribing to the OpenIdConnect middleware's 'OnRedirectToIdentityProvider' event, removing all the cookies (setting already expired date) which name is started '.AspNetCore.Correlation.OpenIdConnect.' and '.AspNetCore.OpenIdConnect.Nonce.' from the request, as the middleware creates the new one for each of them after this event. This worked perfect as I had only one Correlation and Nonce cookie in the browser at the same time.
In version 2.0.0 the logic changed a bit, as these cookies set to the redirect path (by default '/signin-oidc'), so now I cannot remove them at this event (as they're not represented in the request to the identity provider).
My problem is that even they're not in use in that step, after a successful login session when the identity provider redirects back to the client, these cookies represented in the request header, increasing the header size (which is limited by the IIS (because it's request, not response header)).

So the question: after version 2.0.0, do I have any solution to get rid of these cookies dynamically, or the only remaining option is setting their expiration, and hoping that no user will get a 'Bad request' about it? (or is there any big reason what I missed and why I should forget to do this?)

Thanks in advance!
Misi

[Tratcher]

Do you know why you have a buildup of cookies? They're deleted for successful logins. Do you have a user that has so many failed logins within the expiration period? The cookies seem like a symptom of a higher level problem.

[mbalogh89]

Yep, the case is more hypothetical than real.
OK, I understand, that by default there's a very little chance to make this 'stash full', but by options (mainly NonceCookieLifetime and RemoteAuthenticationTimeout or/and the hosting server configuration could change as well lowering the limit) I could be more and more closer to this case. (and not just the failing logins counted as interrupted login sessions are here as well)

[Eilon]

Closing because there are no plans to change anything here. We think the changes we've already made do enough to mitigate the problem of too many cookies.