This past week, we have seen few Cases where OpenIdConnect authentication operations (e.g. login, logout and other features that send POST requests from an external site to the site requesting the operation) were failing in ASP.NET/Core pages (mostly using iframes posting into 3rd party payment authorization gateways). In some Cases, users were logged out after sending the cross-site post requests. Issue was reproducing mostly with the Chrome browsers (version 79 or higher) with Windows Update KB4530689 applied.
The reason is an update in the standard and it's implementation in the latest version of Chrome.
SameSite is a 2016 extension to HTTP cookies designed to provide some protection against cross-site request forgery (CSRF) attacks. It had two values: Lax and Strict, and optionally, you could just opt out without setting anything at all. Most of the OpenIdConnect implementations were opting-out of SameSite, by not setting the property at all, to ensure these cookies will be sent during their specialized request flows.
The upcoming Chrome 80+ will:
- Change default for all cookies to SameSite=”Lax” for those that don’t specify otherwise.
- Will only allow cookies with SameSite=”None” to be used when the “Secure” attribute is also used.
The workaround is easy and it will fix issues with Chrome 79 and will future-proof Chrome 80+. So far, this is the configuration that is doing the trick, with the Forms Authentication is being the optional if your are not using it.
<httpCookies ... requireSSL="true" sameSite="None" />
<forms ... requireSSL="true" cookieSameSite="None" />
<sessionState ... cookieSameSite="None" />
For non-OpenIdConnect scenarios, after the December 2019 updates in .NET framework, the ASP.NET engine has started adding following settings automatically for you (This effects .NET Framework 4.7.2 and 4.8. But for OpenIdConnect authentications and related stuff, you will still need to manually add the above attributes in web.config or in the code):
- SameSite=Lax for Session and Authentication cookies
- SameSite=None for all other cookies (e.g. custom cookies)
Going forward, it would be ideal for app developers to configure their desired cookie policies from code, since the above will blanket all of them if they aren’t configured in code. To understand these recent changes in gory details, we have a 3-part series (Part 1, Part 2, Part 3) that you may wanna look into.
You can also read more details here and here.