Summary

SSO fails with "CSRF attempt detected"

How to reproduce

1. Run FOLIO with front-end and back-end on different hosts with different sites.
2. Configure SSO with POST Binding.
3. Login using SSO

Expected result

Login succeeds.

Actual result

The login doesn't complete and shows this error message:

CSRF attempt detected

SameSite cookie

For details see https://web.dev/samesite-cookies-explained/

Some FOLIO deployments use the same host names for front-end and back-end, back-end is served on a special path. This has the additional advantage of faster responses (less latency) because the browser no longer needs to send extra "preflight" OPTIONS HTTP requests for cross-origin resource sharing (CORS) protection. Example:

https://folio-demo.gbv.de
https://folio-demo.gbv.de/okapi

Some FOLIO deployments use different host names for font-end and back-end, however, the host names belong to the same site. Example for site folio.org:

https://folio-snapshot.dev.folio.org
https://folio-snapshot-okapi.dev.folio.org

The issue this Jira is about happens only when a deployment uses different hostnames for front-end and back-end, and the host names belong to different sites. Fictional example:

https://beispiel.de
https://okapi.example.org

Additional information

hji reports:

After upgrading to Juniper, the SSO for one of our customers is not working due to CSRF. That customer uses different domains between UI and Okapi. Did a quick test and noticed below change can work around the issue.

relayStateCookie.setSameSite(CookieSameSite.NONE)

Please comment if it is safe to do so or maybe there is another better way. Also this change does not seem to help in incognito/private browser mode.

A similar report has been posted on 2022-02-12 on #support Slack channel.

SameSite background information

https://web.dev/samesite-cookies-explained/
https://www.chromium.org/updates/same-site/faq/
https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/
https://samesite-sandbox.glitch.me/