Should SameSite=Lax work after Chrome updates to default SameSite to Lax?

I’m currently using version (with .NET 4.7.2), and acting as a Service Provider.

Due to security constraints we set the following a few months ago:

I was concerned that the 2-minute window for “Lax+POST” was the only reason that our login flow was working correctly but I have tested with Chrome Canary 82.0.4047.0 with the additional flag: –enable-features=SameSiteDefaultChecksMethodRigorously so that would be disabled, and it still works.

Viewing the network I can see the SameSite parameter being set as Lax (request method is POST):

set-cookie: ASP.NET_SessionId=0syfbwutmk4twbjscfrpg5pu; path=/; secure; HttpOnly; SameSite=Lax

I had read in this post the following:

If the SAML session cookie is marked as SameSite=Strict, the browser won’t include it with the SAML response as the sites are different. If the SAML session cookie is marked as SameSite=Lax, the browser still won’t include it as this isn’t considered a top-level navigation action. Specifically, the SameSite specification doesn’t consider Post to be a safe HTTP method.

Is there something else that I need to test against? I would prefer to not set SameSite to None, and would rather use Lax if possible. It appears that it’s working properly, but just wanted to see what I may be doing wrong or if there is something I am not considering.

Thanks in advance.

The browser won’t send the cookie with the HTTP Post to your assertion consumer service URL.

However, once your assertion consumer service redirects to another page on your website, the browser will send the cookie.

The following forum post explains why SSO still works.

I don’t believe there’s any other testing that you need to do.

Thanks for the quick response.

In the section titled SP-initiated SSO, it says:

[quote]If the cookie is lost between sending the SAML authn request and receiving the SAML response, the InResponseTo field cannot be checked. Consequently, this flow is treated the same as IdP-initiated SSO.
For most scenarios, this probably doesn’t matter but strictly speaking it isn’t correct.[/quote]

Is that the reason SSO is still working for me?

Yes, that’s correct.

Strictly speaking this is incorrect as this is an SP-initiated SSO flow and we should be checking the InResponseTo field.

However, with no cookie we have no SAML session state and therefore the SAML response is treated the same way as IdP-initiated SSO.

For most use cases this isn’t a problem. However, it’s good to understand what’s happening.