When is the new default value (On/Strict) for OIDCCookieSameSite useful and applicable?

[DrakezulsMinimalism]

Hi,
I've recently tried to upgrade to the newest release, but it breaks our Azure OpenID flows if we don't turn of OIDCCookieSameSite.

Is it correct that the new default value would only be useful/working for in-house hosted IDP (relays) using the same domain?
Otherwise, I struggle to understand the change. Also, some discussions on StackOverflow said that it might not be any more insecure without SameSite=None, as the protocol has sufficient CSRF protection, e.g. using the State cookie too.

Any advise for proper configuration would be greatly appreciated!

Error message after login in to IDP successfully and being redirected to "/redirect_uri":
Bad Request - Your browser sent a request that this server could not understand.

Logs (indicating that state cookie is missing):

[Wed Jan 10 15:19:07.639486 2024] [auth_openidc:error] [pid 28:tid 140254814987968] [client 172.20.0.1:51458] oidc_restore_proto_state: no "mod_auth_openidc_state__waMp0M7mNJ_rdVLbXMv0rTB31s" state cookie found: check domain and samesite cookie settings, referer: https://login.microsoftonline.com/
[Wed Jan 10 15:19:07.639535 2024] [auth_openidc:error] [pid 28:tid 140254814987968] [client 172.20.0.1:51458] oidc_authorization_response_match_state: unable to restore state, referer: https://login.microsoftonline.com/
[Wed Jan 10 15:19:07.639538 2024] [auth_openidc:error] [pid 28:tid 140254814987968] [client 172.20.0.1:51458] oidc_handle_authorization_response: invalid authorization response state and no default SSO URL is set, sending an error..., referer: https://login.microsoftonline.com/

[zandbelt]

this is not so much about the state cookie - which would have SameSite=Lax - but more about CSRF protection for the session cookie - having SameSite=Strict after the initial after-authentication redirect; since Lax is not working for the state cookie for you, it probably means you're not authenticating in a top-level window, which is not recommended (and hence by default not allowed); can you confirm that?

[DrakezulsMinimalism]

Ups, should've replied here instead of adding a separate comment, I guess.
I've made progress: I'm using OIDCResponseMode "form_post" and I believe this doesn't work well with "Lax" cookies if initiated cross-site, right?
Changing it to "query" solved it, I believe.

[DrakezulsMinimalism]

@zandbelt thanks for the quick support/feedback yesterday! I was not sure if I missed something (hence the subject question), but it makes more sense now.

[DrakezulsMinimalism]

I'm simply accessing (for testing):
https://127.0.0.1:8443 directly in my browser's URL bar. Tested with Edge and Chrome.

[DrakezulsMinimalism]

With OIDCCookieSameSite not present (defaulting):

1. On the first request (initially accessing my URL), I can see the 302 redirect response to Microsoft, where "mod_auth_openidc_state..." is set with
   Path=/; Domain=127.0.0.1; Secure; HttpOnly; SameSite=Lax
2. The request to/redirect_uri after successfully login in to the IDP does then not provide the state cookie indeed
3. Error

With OIDCCookieSameSite Off:

1. SameSite = None
2. The request to /redirect_uri sends the state cookie set in 1.
3. Ok.

[DrakezulsMinimalism]

Sorry, had to edit the above. Naturally, "SameSite=None" is the working case, while "SameSite=Lax" is breaking.