> On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle
> <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.
I was just thinking how much I’d like to discuss this at an IIW. While
developing the DTVA submission I wound up taking IMHO a different stance on
sessions and logout, both technically and conceptually.
>
> > 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.
Most application frameworks are relatively simple - they initiate a session and
maintain it locally. They don’t have a single session record that is maintained
across all applications in a domain. Even frameworks with native support for
federation protocols or form-based SSO wind up using this authentication to
create an application-specific session.
Many also attempt to maintain the session information in an ideally
integrity-protected, time limited, etc cookie, similar to an access token,
rather than having a database within their application for synchronizing the
session state. You wind up needing an additional state mechanism in this case
to record invalidated sessions/tokens, which is typically not provided by
frameworks.
This was one of the primary focuses of my DTVA submission - a REST API where
you could submit the `sid` of a token in order to find out if it had been
invalidated. If you were using some cookie-based storage mechanism, tossing the
`sid` in let you make this API call after discarding the id_token - hopefully
allowing for application developers to add checks for an invalidated session as
part of their global pipeline.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
