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.
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?) -- Annabelle Richard Backman Amazon – Identity Services From: Bill Burke <bbu...@redhat.com> Date: Wednesday, March 28, 2018 at 12:10 PM To: "Richard Backman, Annabelle" <richa...@amazon.com> Cc: Mike Jones <michael.jo...@microsoft.com>, Roberto Carbone <carb...@fbk.eu>, "oauth@ietf.org" <oauth@ietf.org>, Nat Sakimura <n...@sakimura.org> Subject: Re: [OAUTH-WG] What Does Logout Mean? On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle <richa...@amazon.com<mailto:richa...@amazon.com>> wrote: I'm reminded of this session from IIW 21<http://iiw.idcommons.net/What_Does_%E2%80%9CLogOUT%E2%80%99_mean%3F>. ☺ I look forward to reading the document distilling the various competing use cases and requirements into some semblance of sanity. > If the framework has no way of invalidating a session across the cluster… Is this a common deficiency in application frameworks? It seems to me that much of the value of a server-side session record is lost if its state isn’t synchronized across the fleet. "modern" apps are REST based with Javascript frontends, but there's still a ton of "old school" developers out there. Was involved with developing an application server for over a decade (JBoss)...There were many app developers that didn't want to store app session information in a database (as David says) or deal with the headaches of session replication so they just set up their load balancer to do session affinity (sticky sessions). That way the login session was always local. If the oidc logout spec allowed the client to register logout callback tied to the token's session (like maybe during code to token), that might be a simple way to solve many of these issues too.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
