rp-backchannel-rpinitlogout: should not callback the initiating RP

[zandbelt]

When my RP initiates the backchannel logout towards the OP, it also kills its own session before doing so. It does not expect the OP to callback to itself, the session is already killed by then. The test suite seems to assume that the RP needs a callback to kill the session, and the initial request is merely a redirect to trigger that.

The logout spec points to the session management spec which says in https://openid.net/specs/openid-connect-session-1_0.html#RPLogout:

An RP can notify the OP that the End-User has logged out of the site and might want to log out of the OP as well. In this case, the RP, after having logged the End-User out of the RP, redirects the End-User's User Agent to the OP's logout endpoint URL.

so though it does not say that the OP should not callback the initiating RP, I believe that follows out of the current text nevertheless: calling back is pointless because the RP should have already killed its own session, therefore I suggest to adapt the test suite for that.

[rohe]

This is about the post_logout_redirect_uri again, right ?
https://openid.net/specs/openid-connect-session-1_0.html#RedirectionAfterLogout
If not present then no call back to the RP is expected (or wanted). If present then the RP do expect a callback.

[zandbelt]

no, it is about the logout request itself from OP to RP

[rohe]

OK, so about the backchannel_logout_uri then ?

[zandbelt]

what about it?

[rohe]

Since we're dealing with Single Logout here the OP will try to log you out from all the RPs that have active sessions for the user.
If you have specified a backchannel_logout_uri (or frontchannel_logout_uri for that matter) then the OP will contact the RP otherwise not.

[zandbelt]

yes, and my point is that the initiating RP already killed the session, as the spec suggests, so does not need the callback

[rohe]

So, you can leave out the backchannel_logout_uri but then I would say that you don't support backchannel logout.
There is nothing in the spec that says that the OP should refrain from doing a callback to the RP that initiated the end session.
Seems like this is something for the mailing list to discuss.

[panva]

An RP should still expect to get both front and back-channel notifications regardless of being the RP that initiated that logout. Think about a setup where the initiation is just a frontend webpage but session information is stored on the backend as well. We should not be exempting those scenarios.

[zandbelt]

Well the spec says that whatever the RP would have to do on the incoming logout request, it should have already done that before initiating the request towards the OP...

Anyway, I'm thinking:
a) we should make OIDC certification require the RP to deal with incoming backchannel requests that do not have a session associated with them gracefully (for both RP and OP), so return the equivalent of "OK"
b) if we do not do a) we'd have to come up with another test that actually simulates a different RP initiating the request, so the backchannel logout request to the RP being tested finds an existing session

we may not want to go b) anyhow...

[panva]

Shouldn't we just allow any of 200, 501 or 504 as the specs indicate then? No honestly, since the OP isn't likely going to do anything if it gets anything else than a 200 OK if i was writing an RP that accepts backchannel logout requests if i didn't find the session i'd still respond with 200.

[zandbelt]

agreed, that's what I'm proposing as well: I also think it should be made explicit as part of the certification requirements, to cater for interoperability

[selfissued]

The OP is required to send logout messages to all RPs that it believes are logged in with it, including the RP sending an RP-Initiated Logout message to it. That's true for all three OP-Initiated logout mechansims (Session, Front-Channel, Back-Channel). Nowhere does the spec say that the RP should try to log itself out before sending the RP-Initiated Logout message. (It can always clear its login state at any time, so doing so isn't a spec violation.)

I do agree that RPs should gracefully handle logout messages if they're already logged out - effectively making them idempotent.

This is a valuable discussion. I'll file a spec issue making sure that these things are completely clear in the logout specs. Thanks all!

I believe that this issue should be closed on this basis.

[zandbelt]

Nowhere does the spec say that the RP should try to log itself out before sending the RP-Initiated Logout message. (

As mentioned earlier, it does:

The logout spec points to the session management spec which says in https://openid.net/specs/openid-connect-session-1_0.html#RPLogout:

An RP can notify the OP that the End-User has logged out of the site and might want to log out of the OP as well. In this case, the RP, after having logged the End-User out of the RP, redirects the End-User's User Agent to the OP's logout endpoint URL.

and exactly because of that, it does not make sense to callback the initiating RP, because: assuming the OP believes the RP implements the spec in the way above, it can assume that the RP does not have a session any longer.