What are the implications of the Chrome 80 SameSite cookie change?

Starting on February 17th 2020 Google will start adjusting how Chrome 80 sends cookies between different sites. This might break services connected to Feide, and means service providers MUST take action to ensure their services will still be able to login using Feide in the future.

The problem may affect logins, depending on how the service works, either for all, or some of the users. The problem will affect logouts when these are initiated from the Feide side, and may affect logouts initiated by the service.

Details: SameSite Cookie behaviour change and Feide

In Chrome 80 the default behaviour with regards to the cookie attribute SameSite changes. Cookies without a SameSite attribute will be treated as SameSite=Lax. Prior to this change cookies could be used cross-site by default and the SameSite cookie attribute was opt-in. This change has implications for services connected to Feide.

For services using SAML

When Feide responds to an authentication request it uses the HTTP POST method, which means any application cookies previously set will not be sent as part of the response. Chrome has a temporary measure in place, where it still allows for sending these cookies if they are less than 2 minutes old, but please note that depending on how the service uses cookies, this might not be a sufficient stop gap.

For logouts initiated by the service, depending on the configuration, POST might be used by Feide to send the logout response, which will also lack any application cookies. Normally, logout will not occur within 2 minutes, and so, the temporary measure will not apply either.

For logouts not initiated by the service itself, the logout request is sent to the service in an iframe, and regardless of whether this is a GET or a POST request, no application cookies will be sent.

For services using OpenID Connect

If the authentication uses the response mode form_post, the response from Feide will trigger a POST request to the callback URL, which means that any application cookies previously set will not be sent in this case. The 2 minute window mentioned above will apply though, allowing sending of the cookies anyway if they are less than 2 minutes old. As noted above, this might not be a sufficient stop gap, depending on how the service uses cookies.

Changes that need to be made on the Service Provider side

All SAML applications, and any OpenID Connect applications that use the form_post response mode may be affected. If the application depends on cookies to reconcile the response with its internal state and the cookies are not marked as SameSite=None it is affected. To address the issue service providers are advised to:

• Review the list of unsupported browsers.

• Adjust applications or update libraries as needed to ensure that SameSite=None is used for cookies. Please refer to SameSite cookie recipes for guidance on how to implement this fix for your use cases.

Changes being made on the Feide side

Please note that these changes only relate to the login service itself, and will not mitigate service specific issues as mentioned earlier.

• The cookies that Feide uses for its authentication services will be changed to specifically set the SameSite attribute to None.

• There will be additional fallback cookies set (with a _nss suffix) to handle the case of legacy browsers that do not support the SameSite=None setting.