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

Issue #1185 resolved
Ryo Ito created an issue

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.

Comments (7)

  1. 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?

  2. Ryo Ito reporter

    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.

    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.

  3. 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.

  4. 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.

  5. Nat Sakimura

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

  6. Log in to comment