SameSite Cookie changes in ASP.NET/Core and how it impacts browser (specifically Chrome)

This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.

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). Issue was reproducing mostly with the Chrome browsers.


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.


New Changes:

As of Chrome 79, the  SameSite cookie now have three values: Lax (default),Strict and None. This breaks OpenIdConnect authentications and potentially other features your web site may rely on, these features will now have to use cookies whose SameSite property is set to a value of “None”.


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:

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" />



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. You can read more details here and here.

REMEMBER: these articles are SYNDICATED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.