Back-Channel Logout Response and HTTP 504 Gateway Timeout

Issue #1487 resolved
Andrii Deinega created an issue

The section states that

If the local logout succeeded but some downstream logouts have failed, the RP MUST respond with HTTP 504 Gateway Timeout.

from my personal experience, lots of network intermediaries can easily override 5** errors and particularly, HTTP 504 (Gateway Timeout) status code. It isn’t uncommon to see all sorts of such network components between an RP and OP these days.

Furthermore, what’s maybe even more important, is that an RP say behind a K8S ingress controller could be literally unavailable or just overloaded. Thus, the controller has legitimate reasons to respond with 503 to backchannel_logout_uri as well as to any other endpoint on the RP side.

I suggest relying on a special status in the error and error_desciption parameters just like it happens in rather than relying on HTTP 504 to handle this situation. Otherwise, it seems to be very easy to “misinterpret“ obtained results or simply lose “Back-Channel Logout” requests.

Comments (11)

  1. Michael Jones

    I’m curious @Brian Campbell , @Filip Skokan , and @Joseph Heenan what you think of this suggestion.

  2. Michael Jones

    @Andrii Deinega , you may not be aware of this but it’s necessary to sign an OpenID Contribution agreement to contribute to OpenID specifications. I don’t see one on file for you or GlobalLogic at Please complete one, per the Participation instructions at Let us know when you’ve done so.

    While we welcome your useful contributions, until you make it clear that they pose no IPR risk to the OpenID Foundation, we may not be able to act upon them.

  3. Joseph Heenan

    I think I’d tend to agree that providing a providing a more detailed error is perhaps useful, particularly if it’s intended that the callee takes some action based on the response - though this section also doesn’t appear to give any guidance to how these errors should be handled by the recipient. e.g. does 504 implicitly mean “this request might succeed if you try again later” in this case? If it does returning it for all kinds of downstream failures probably isn’t helpful and there should be different codes for temporary vs more permanent failures.

    The same section also says:

    If the logout failed, the RP MUST respond with 501 Not Implemented.”

    which again seems like it’s overly broad and the RP might want to reply with a different code if the logout might work later.

  4. Filip Skokan

    If the local logout succeeded but some downstream logouts have failed, the RP MUST respond with HTTP 504 Gateway Timeout.

    I would say this sentence could be removed altogether, I have a hard time imagining it being interoperable since “some downstream logouts have failed” is a) not something the OP is likely to be aware of and b) doesn’t have any defined consequence at the OP.

    I can get behind two codes, 200 for success, 400 for “i failed to validate your message”. The other mentioned status codes imho do not add value to the specification.

    Rather than enumerating a number of codes with under-defined behaviours a catchall language about “any other status code returned by the RP is to be handled at the OP’s discretion / is out of scope of this specification but may further defined by the OP” would make sense to me.

  5. gffletch

    I agree with Filip. I don’t think we should put any meaning on any 5XX codes other than something at the transport layer happened and the state of the transaction is unknown. Today there can be many intermediaries between the OP and RP which could return 5XX error codes so there is no way for the OP to know whether the request even reached the RP.

  6. Log in to comment