Multiple ASP.NET Core OAuth Correlation cookies

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

We’re using ASP.NET (v6) with Angular, using Cookie authentication to the back end, and proxying to an API (secured via OAuth). This is working the majority of time, but we are seeing occassions where the server is generating .AspNetCore.Correlation.oauth.$RANDOM cookies with a null expiry. Using Chrome, the header appears as:

set-cookie: .AspNetCore.Correlation.oauth.ativ9Y_r)bPnrqIOXsbWR5I.......; expires=Thu, 01 Jan 1970 00:00:00 GMT; Path=/

A correctly generated cookie during the OAuth cycle looks like:

set-cookie: .AspNetCore.Correlation.oauth.BSPC3Ydwq95MYo0t-T4MxWMrsIVN_q_zTwR-FhdgizA=N; expires=Fri, 15 Jul 2022 05:03:46 GMT; path=/signin-oidc; secure; samesite=none; httponly

(So secure, httponly are missing, and the expires option is incorrect)

The cookie is attached (sometimes) after the OAuth cycle, but the cookie is rejected and the Signin cycle starts again. After a failure, each subsequent request to /signin-oidc gets an additional set-cookie header (resulting in multiple cookies).

Nothing appears in the Asp.Net server logs, and clearing the cache resolves the issue.

We are running in a load-balanced environment (k8s+Docker) with multiple containers behind the same ingress URL.

Expected Behavior

The cookie is generated and passed around correctly.

Steps To Reproduce

Exact reproduction steps are unknown.

Exceptions (if any)

No response

.NET Version

5.0

Anything else?

No response

Issue Analytics

State:
Created a year ago
Comments:28 (18 by maintainers)

Top GitHub Comments

1reaction

danielbecroftcommented, Jul 16, 2022

expires=Thu, 01 Jan 9170

😕

I’m assuming that’s a typo for 1970? We should look at how we’re generating these cookies. @Tratcher PTAL.

Yeah, sorry it was a typo. Should be 1970. Had to transpose from a screenshot.

0reactions

danielbecroftcommented, Sep 7, 2022

Thanks @Tratcher , it is getting populated with an anonymous user, but some of our code checks this, and issues a challenge immediately. It’s this logic that I now think is actually incorrect, so we’ll look at fixing that later.

Our change to use MaxAge as well as ExpireTimeSpan has resolved the issue. The MaxAge stops the cookie getting sent on the subsequent /signin-oidc request, and the loop and multiple cookies no longer occurs.

I’m going to close this issue now, as we have been able to resolve it. Thanks @Tratcher and @HaoK for your assistance.