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

David Waite <david@alkaline-solutions.com> Wed, 28 March 2018 18:25 UTC

Return-Path: <david@alkaline-solutions.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC161201F2 for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 11:25:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzXsrfpU94pq for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 11:25:28 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id B3221124E15 for <oauth@ietf.org>; 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 alkaline-solutions.com (Postfix) with ESMTPSA id 6AA2D3160C; Wed, 28 Mar 2018 18:25:25 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <3531401A-6D49-4447-AC05-B93E7798C5FA@alkaline-solutions.com>
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: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com>
Cc: Bill Burke <bburke@redhat.com>, Mike Jones <Michael.Jones@microsoft.com>, Roberto Carbone <carbone@fbk.eu>, "oauth@ietf.org" <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>
To: "Richard Backman, Annabelle" <richanna@amazon.com>
References: <DM5PR00MB02932B889807DF883C006512F5A30@DM5PR00MB0293.namprd00.prod.outlook.com> <CABRXCmykJMcy-PdapRURd7YuZxfMbD9dHkf89AKxObM_2bAqKQ@mail.gmail.com> <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/F5H1zgRk4jysI8v9nOjkrYmoaHI>
Subject: Re: [OAUTH-WG] What Does Logout Mean?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2018 18:25:31 -0000


> On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle <richanna@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