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

Bill Burke <bburke@redhat.com> Wed, 28 March 2018 19:09 UTC

Return-Path: <bburke@redhat.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 B2E5B1275AB for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 12:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 QmK6JyPLmath for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 12:09:13 -0700 (PDT)
Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1700A1274D2 for <oauth@ietf.org>; Wed, 28 Mar 2018 12:09:13 -0700 (PDT)
Received: by mail-ua0-f177.google.com with SMTP id n20so2207024ual.7 for <oauth@ietf.org>; Wed, 28 Mar 2018 12:09:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y4Ueb+0GaQqH+PwqAFVjs8gkg4Z79ukE3PL1eINHueM=; b=r2wAvEN/OWXuZlEMxble8m3E+EWIoQazt7otp6eeC/nf7U0c/fhbnJjnhG3U/1Qhy5 HHIS1Ad6ZV4D0KpHUzpAycUTeJisFLKoHnkiUPhrYQrmuh+Ws5vY3Pe9j30dtbuIAYHd 8IXhg4kRc4XUTi+vbe3AFhQYIP1x8B6F6c+cJTwuOBP1ATtHaQnEmgjeLauoEqPCD195 gaZR0n0l4Rl6R4n5evEZ5vCmA3p7VJHPUyfV/z9yzypOZlZWM8ODgRkZnMWiYp7hOadD mJbZ+qUr0USuQxmX5L1Hul9LGCxsLz9DbGOmePKdamiaEcFQnglQtmb+rkDOAghqnEmL xeKg==
X-Gm-Message-State: AElRT7EAwyq6ya9pS4rY42EqO1fRe2jSbgrRuHrHEX+5n+uy5vN+rzCg hR8Cp/NkizFt4El4RTS9iXnsskHJHmgLDB76wL+DZw==
X-Google-Smtp-Source: AIpwx4/sZUHsJTFubXalgshjemxcLBwY+v5w0v7RzqXWXxdL9h3hw++EEJFtn1IX2faac/0vaQiMoXYPrbhEO4rdSfw=
X-Received: by 10.176.78.203 with SMTP id x11mr3239546uah.91.1522264152120; Wed, 28 Mar 2018 12:09:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.13.199 with HTTP; Wed, 28 Mar 2018 12:09:11 -0700 (PDT)
In-Reply-To: <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com>
References: <DM5PR00MB02932B889807DF883C006512F5A30@DM5PR00MB0293.namprd00.prod.outlook.com> <CABRXCmykJMcy-PdapRURd7YuZxfMbD9dHkf89AKxObM_2bAqKQ@mail.gmail.com> <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com>
From: Bill Burke <bburke@redhat.com>
Date: Wed, 28 Mar 2018 15:09:11 -0400
Message-ID: <CABRXCmy6aUO_1=Sp08U=B2mV22oP96-R9t16sDsZbo0vDX6fnQ@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, Roberto Carbone <carbone@fbk.eu>, "oauth@ietf.org" <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>
Content-Type: multipart/alternative; boundary="089e08e4f9930ab68a05687dbeba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/o9C_Cm-rDvkm5ivZ7ZCQfYNZ7Lg>
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 19:09:16 -0000

On Wed, Mar 28, 2018 at 1:40 PM, 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.
>
>
>
> > 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.