RP-Initiated Logout specification and the back channel
Issue #1492
closed
A common scenario for Web applications is to have their own session mechanisms. Among all other things, these mechanisms allow specifying the maximum and idle session timeouts. For example, the Apache Tomcat session times out after 30 minutes by default.
From the security posture, the information about session timeouts from RPs is useful because it allows invalidating the user’s session on the OP side (and ATs) once there aren’t any other active sessions anymore. That happens, for example, when a user turns off his laptop and goes home. There could be a number of other good reasons for the OP to know that the user doesn’t use a particular RP anymore.
Right now, the specification makes an emphasis on the front channel
An RP requests that the OP log out the End-User by redirecting the End-User's User Agent to the OP's Logout Endpoint.
and allows using both HTTP GET or POST methods to send the logout request to the OP which is great.
Although, it’s technically possible for the RP to request the OP to log out the user using the backchannel when his session times out (using the POST request). It’s impossible to say whether this use case was considered before but if the WG finds it to be a legit one, I suggest outlining it and/or changing the wording for the RP-Initiated Logout section.
Comments (7)
-
reporter
-
The emphasis on front channel redirect is very much intentional. The OP needs to have its own front-channel involved should it need to clean it up, rely on loading cookies to perform the logout, or trigger its own front-channel logout signals to other clients. The OP may also need to show an end-user prompt.
-
+1 to @panva ‘s observation. I don’t believe that adding back-channel RP-Initiated Logout functionality makes sense.
-
reporter
An online banking portal I use logs me off after a short period of inactivity. Does the portal need to notify the authentification server/service (let's consider it's an OP) that such an event has occurred? I believe, the answer is yes. The front-channel simply won't always work… because of its nature.
In addition to that, our internal security team puts a quite strong requirement on us, we must invalidate ATs right after a user gets logged off. We just cannot do much about it other than invalidating ATs.
This is why I'm looking for a reliable mechanism on an RP's side. Moreover, on OP's side, I would like to understand why and how exactly thy logout event has occurred; a user clicked on the "sign off" button vs "the user was logged off because he was inactive".
There are other things.
The specification assumes (at least the way I am reading it) that a user always opens the end_session_endpoint with his browser which holds his "active" authentification state (using a cookie or whatever else it could be). What will happen if it isn't the case? This is also the reason why the back-channel isn't going to work well, there is no way for an RP to know about the user's authentification state on the OP.
Hope my explanations make some sense.
Lastly, in my own experience, everything related to the SLO (Single Logout) turns out to be way harder than it seems to be in the first place, especially when I deal with a bit more than trivial setups.
-
Don’t get me wrong, i’m not dismissive of the benefits of having a back-channel signal from the RP. That being said, RP-Initiated Logout is not such mechanism and this late in the process it doesn’t feel like the right place to slap new functionality on to.
-
- changed status to closed
On the 16-May-22 working group call, there was agreement that it wouldn't be appropriate to add a back-channel rp-initiated logout mechanism to the existing RP-Initiated Logout specification. As discussed in this thread, such a mechanism could be defined, but this would be a different specification. There was agreement to close this issue on that basis.
-
reporter
Per https://lists.openid.net/pipermail/openid-specs-ab/2022-May/009077.html there were these things
Vittorio said a back-channel flavor could be based on SSE
Vittorio doesn't know what the carrot would be for the providers to support a back-channel rp-initiated logout
It could be based on SSE, I agree. How exactly will the OP subscribe to such events from its RPs? My understanding is that normally, the flow of such events goes in a different direction. I understand it’s technically possible, I just find that to be over complicated, more than it should be.
I tried to explain the carrot’s part and when it’s needed. It’s a reliable mechanism to tell the AS that a user gets logged off. It improves the security posture.
- Log in to comment
In addition to that, it may make sense to change the wording
because the RP can (technically) use the backchannel just for the same purpose. In my experience, it isn’t always necessary to redirect a user to the OP and use some post logout URLs and so on.