SameSite Cookie and SAML 2.0
With Chrome's building a more private web initiative, Google has announced that future versions of Chrome will begin enforcing secure-by-default handling of third-party cookies. This means that any cookie without a SameSite policy assigned to it will automatically be upgraded to
SameSite=Lax and cross-origin requests will only have cookies attached to them when they use the GET verb.
This change was initially introduced with the stable release of Chrome 80, but was later rolled back. Soon it will be reintroduced with other browsers following suit.
This new policy will only allow cookies set with the
Secure cookie flags to circumvent this new feature, provided they are being accessed from secure connections (HTTPS).
Our SAML SP component makes use of a correlation cookie during the SAML authentication flow and, if using the HTTP POST binding, is affected by these SameSite cookie changes.
This correlation cookie remembers security data such as the request ID, relay state, and the ASP.NET authentication properties.
By default, the correlation cookie has its
SameSite flag set to
None and a
CookieSecurePolicy.SameAsRequest. No changes will be required for most users once browsers roll out the SameSite cookie changes.
SameSiteMode of the cookie and that you are running under HTTPS.
To debug, we recommend that you check that the correlation cookie is being set correctly in the browser during the redirect to the IdP's SSO endpoint and that the correlation cookie is present in the redirect to the SP's ACS endpoint.
Older versions of Safari do not support
SameSite=None. When Safari meets an unexpected SameSite policy, it defaults to
Strict. This will prevent the Cookie from being sent across domains. To resolve this issue, you will need to implement browser sniffing and set the Same Site Policy to
unspecified, as recommended by Microsoft. This approach stops Safari from setting an incorrect policy, recreating the default behavior of other browsers.