- edited description
Back-Channel Logout Response and HTTP 504 Gateway Timeout
Issue #1487
resolved
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 https://datatracker.ietf.org/doc/html/rfc6749#section-5.2 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)
-
reporter
-
reporter
- edited description
-
I’m curious @Brian Campbell , @Filip Skokan , and @Joseph Heenan what you think of this suggestion.
-
@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 https://openid.net/executed-contribution-agreements/. Please complete one, per the Participation instructions at https://openid.net/wg/connect/. 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.
-
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.
-
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.
-
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.
-
reporter
@mbj, I've signed an OpenID Contribution agreement.
-
Agree w/ Filip and George.
-
-
- changed status to resolved
- Log in to comment
