Mention of POST requests and SameSite cookie attributes (RP Initiated Logout)

[Ryo Ito]

The RP Initiated Logout specification allows the RP to send a POST request to the OP's Logout Endpoint.
It is well known that this is associated with the SameSite attribute, so does the specification need to mention it?

Since specifications such as SessionManagement mention Third-Party Content, I think it's necessary in this specification as well.

[Michael Jones]

How is doing a POST to the logout endpoint related to SameSite cookies and how does doing so differ from doing a GET to the same endpoint? (I’m not an expert in these (changing) browser behaviors.)

What specifically would you want us to say in the RP-Initiated Logout spec?

[Ryo Ito]

Currently, latest Google Chrome will set the value of the SameSite attribute of the HTTP cookie to "Lax" by default. If a user has recently logged into the OP and a session cookie with SameSite=Lax has been issued, the session cookie will not be sent on the OP when a POST request is sent from RP.

https://medium.com/@ritou/samesite-cookie-attributes-redirect-behavior-62efa5c67910

This has the same effect as response_mode=form_post and SAML's POST binding.I believe that OP developers who provide RP Initiated Logout are aware of this issue, but it would be kind to those who are not that way to have the following mention in the spec.

# User Agents and SameSite Cookie

Note that at the time of this writing, some User Agents (browsers) are starting to block sending cookie by cross-site POST request by default.
This can prevent the ability for logout from the OP when request from RP. 
OPs that support this specification need to prevent this by setting the appropriate SameSite attribute in the associated cookie or checking the value of the session at the next endpoint through the logout endpoint.

‌

[David Waite]

SameSite behavior controls whether individual cookies are sent when a request is made cross-site - such as a navigation to a new site, XHR/fetch to another site, or embedded iframes with a different site than the top-level window. It is primary a security mechanism (for things like XSRF) rather than a privacy mechanism, but it does lead to cookies being blocked in many traditional OAuth/OIDC scenarios (and SAML scenarios).

SameSite Policy set on Cookie	Behavior
None	Cookie may be sent cross-site
Lax	Cookie should only be sent cross-site when using a “safe” HTTP method - GET, HEAD and OPTIONS qualify, POST and PUT do not.
“Chromium”	Compatibility level in current Chrome, the default for most Chromium-based browsers. In addition to LAX behavior, cookies may also be sent on cross-site POST when the cookies are less than a certain number of minutes old (2 minutes?).
Strict	Cookies are not sent cross-site for any HTTP request

The “Chromium” level was specifically made to reduce breakage in SSO scenarios, although you may still get errors for Chrome users if the user takes a bit longer to authenticate (such as when you do a sent OTP challenge). It is a temporary workaround without a stated sunset date AFAIK.

The existing mitigations for POST that we have for SSO should apply for SLO as well - if you support POST and you require local cookie state on the HTTP request, you should do a local domain redirect first. Once a redirect happens within your domain, you should see cookies sent with the next HTTP request.

[Michael Jones]

There's currently Implementation Considerations text about this at https://openid.net/specs/openid-connect-frontchannel-1_0.html#ThirdPartyContent and https://openid.net/specs/openid-connect-session-1_0.html#ThirdPartyContent . If people want to see these notes updated, please supply the proposed revised text.

[Michael Jones]

Given this is already addressed in the two related specs that are directly affected by these changes, I would propose that we close this issue with no further action unless someone wants to propose specific related text changes for the RP-Initiated Logout specification.

‌

[Nat Sakimura]

It was proposed to close this ticket in a week time if there is no objection after reaching out to Ryo Ito.

[Michael Jones]

Closing, per the decision on the 11-Apr-22 working group call.