Working system with cookies set to SameSite=Strict?

[intrapid]

Hi!

What are the conditions needed to be able to have working system with state and session cookies set to SameSite=Strict/Lax?

When I try and set OICDCookieSameSite to On, it breaks the login flow. It seems that the redirect at login causes the web browser to block the mod_auth_openidc_state_xxx cookies from being sent. That then causes mod_auth_openidc to fail - even if the rest of the information is sent.

I got the same result in Firefox and Chrome/Edge/Brave running default config. I'm guessing it might be related to redirect tracking protection.

BTW I'm on version 2.4.12.3.

[zandbelt]

this works for me; the state cookies and the first Set-Cookie response header setting the session cookie will have SameSite=Lax applied to them (as this is neccesery to make the login flow redirects work), subsequent updates of the session cookie will have SameSite=Strict in the Set-Cookie response header; you'll have to debug using the browsers development mode

[intrapid]

Thanks! If it's working for you with current browsers I need to do some more debugging. Firefox flat out says it's blocking the cookies due to redirects. I'll dig deeper.

[intrapid]

After some more debugging I have confirmed that all browsers does indeed block all mod_auth_openidc_ cookies from being sent after the login redirection - when the cookies are set to SameSite=Lax using OICDCookieSameSite On.

It's the browser's cross-site request forgery (CSRF) protection that blocks the cookies.

This protection only triggers when the cookies are set to SameSite=Lax and the browser makes a POST request on the redirect from the identity provider to OIDCRedirectURI.

The POST request only happens when OIDCResponseMode is set to form_post.

Unless there are other settings at play as well, my findings are that OIDCResponseMode form_post and OICDCookieSameSite On are incompatible with each other. If I change one or the other back to default, everything works fine.

For the record, I'm using implicit flow with form post so I also have OIDCResponseType set to id_token.

[zandbelt]

it is not so much that the primitves are incompatible, it is the same site spec that does not allow this; also, for the record: you should not use the Implicit grant type since it is deprecated and deemed insecure

[intrapid]

Thanks!

Regarding implicit grant in OIDC I did try to find out the status from some official source but the open id connect core specs says nothing. Maybe it can be found somewhere else.

The latest OWASP recommendations are: "The implicit flow in OAuth only is deprecated, yet is still a viable solution within Open ID Connect (OIDC) to retrieve id_tokens. "

Others say the similar things, for instance auth0: "Although OAuth now discourages the use of the implicit grant for obtaining access tokens in SPAs, the scenario addressed by Implicit Flow with Form Post is completely different and is unaffected by the security issues that led to discouraging use with SPAs. Specifically, Implicit Flow with Form Post applies to traditional web apps as opposed to SPAs."

I'm sure you have more info but from what the the information above the implicit flow doesn't look deprecated or even discouraged when it comes to open id connect and non-SPAs.

[intrapid]

What I'm looking for is an authentication flow that works with traditional web apps and doesn't require outbound communication from the backend to the Open ID provider - similar to SAML.

Maybe that's not possible.