Re: [OAUTH-WG] What Does Logout Mean?

["Richard Backman, Annabelle" <[e-mail]>]

> Then,isn't any backchannel logout specification more of a framework than an actual protocol?

Comments inline.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Bill Burke <[e-mail]>
Date: Wednesday, March 28, 2018 at 2:35 PM
To: "Richard Backman, Annabelle" <[e-mail]>
Cc: Mike Jones <[e-mail]>, Roberto Carbone <[e-mail]>, "[e-mail]" <[e-mail]>, Nat Sakimura <[e-mail]>
Subject: Re: [OAUTH-WG] What Does Logout Mean?




On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle <[e-mail]<mailto:[e-mail]>> wrote:
That makes somewhat more sense to me if we’re talking about applications with sticky sessions. Adding a session-specific logout URI introduces security concerns (e.g. how does the OP validate the URI) and only works if the RP can provide URIs that target individual hosts in their fleet. The “is this SID valid?” endpoint solution that David described doesn’t scale and depends on SID (which is OPTIONAL). Both shift the burden of state management onto the OP, which may not be in any better position to handle it.


FWIW, our OP implementation allows RPs to register their node specific logout endpoints at boot.  This request is authenticated via client authentication.  We also extended code to token request to transmit the local session id.  The OP stores this information.  Backchannel logout POSTS to each and every registered node and transmits a JWS signed by the OP containing the local session ids to invalidate.  That's been enough to cover all the weirdness out there so far.
[richanna]
What does “at boot” mean in the context of OpenID Connect? Do you mean that for every logout, the OP makes a Backchannel Logout request to each of the client’s node-specific logout endpoints? If that’s the case, why can’t the client make those calls themselves, from whichever host happens to receive the Backchannel Logout request?

Since the client only cares about node-local state, they should be able to maintain the mapping between OP session IDs and local session IDs on their side.
[/richanna]
This seems like something that needs to be addressed in the client implementations rather than in the specification. Especially when we consider that there are implementation-specific questions lurking in the edge cases. (e.g. what happens when a user comes in with valid cookies, but no server-side session state?)


Then,isn't any backchannel logout specification more of a framework than an actual protocol?
[richanna]
It’s neither. To quote the abstract, it’s “…a logout mechanism….” I think it’s appropriate for the specification to focus on those aspects of the mechnanism that must be standardized in order to have interoperability between OPs and RPs. What we’re discussing falls outside of that, as sticky session implementations are themselves proprietary and the client can address this issue internally without impacting the interoperability of the logout mechanism.

Put another way, the requirement is to get the logout signal from OP to RP. What the RP does with it at that point is up to it.
[/richanna]

--
Bill Burke
Red Hat