- Issue created by @Kyber
One common configuration in our applications is to enforce SameSite=strict on session cookies.
This avoids issues with cross domain request attacks. The browser will not pass the session, so it can't be abused to do bad things in a blind post or get.
We've used this configuration with Drupal for many years.
However, openid_connect appears to rely on session state to complete the authentication. As a result, if an external OIDC provider submits back to openid_connect, and the browser does not pass the session cookie where it was kicked off, authorization fails until the page is refreshed.
Firefox (IMO correctly) does not pass a SameSite=strict session cookie when the request comes from another domain (Chrome does, but that is probably a security failure on their part).
If a "window.location.reload()" is injected into the openid_connect endpoint after the failure then Firefox treats the request as same domain, and the authentication succeeds.
For now, we will remove SameSite=strict on the PHP session cookie, and rely on Drupal's own mitigations against this. If it turns out this is a problem, security-wise, we might try injecting a window.location.reload() into the openid_connect module on the endpoint url.
But SameSite=strict would be nice to have, and so far this issue only impacts this plugin and only in this one part of the transaction. It seems (to me) that an OIDC authentication should be possible to complete without relying on the PHP session cookie to keep track of the authentication state, but I certainly understand if you don't consider it worth doing.
Active
3.0
Code