On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle < richa...@amazon.com> 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. > 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? -- Bill Burke Red Hat
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
