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

David Waite <> Wed, 28 March 2018 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC161201F2 for <>; Wed, 28 Mar 2018 11:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.425
X-Spam-Level: *
X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jzXsrfpU94pq for <>; Wed, 28 Mar 2018 11:25:28 -0700 (PDT)
Received: from ( [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by (Postfix) with ESMTP id B3221124E15 for <>; Wed, 28 Mar 2018 11:25:28 -0700 (PDT)
Received: from [IPv6:2601:282:281:2e95:4911:e1e9:fd59:ca0a] (unknown [IPv6:2601:282:281:2e95:4911:e1e9:fd59:ca0a]) by (Postfix) with ESMTPSA id 6AA2D3160C; Wed, 28 Mar 2018 18:25:25 +0000 (UTC)
From: David Waite <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1BE0F43-68A9-4728-8134-E05E4AC83580"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 28 Mar 2018 12:25:23 -0600
In-Reply-To: <>
Cc: Bill Burke <>, Mike Jones <>, Roberto Carbone <>, "" <>, Nat Sakimura <>
To: "Richard Backman, Annabelle" <>
References: <> <> <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [OAUTH-WG] What Does Logout Mean?
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Mar 2018 18:25:31 -0000

> On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle <> wrote:
> I'm reminded of this session from IIW 21 <>. ☺ 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.