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

"Richard Backman, Annabelle" <> Wed, 28 March 2018 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A127120227 for <>; Wed, 28 Mar 2018 13:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RThjxJ8tGsu3 for <>; Wed, 28 Mar 2018 13:10:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5423F1200F1 for <>; Wed, 28 Mar 2018 13:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=amazon201209; t=1522267804; x=1553803804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xdUkRpNZbmbdFU9fJhVp4jJG/c/pQDbrQhQKqFUYm7I=; b=TBG4l3wsN1HmGgQwbBUiwqQXfuwDIADq3MCxBsYsIhlibLQWSP8kHA49 4ePGrjJYnHYgudVkVvonKV6TcIkFwPkuqRWwWKVyGbx20c/o9b5qiDhb+ OfyznP3rVN+zvt1o9t2xIhoevu1e/lZ1y5XaeyfWBbG06fdO+AwM/J0CP s=;
X-IronPort-AV: E=Sophos;i="5.48,372,1517875200"; d="scan'208,217";a="713827208"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2018 20:10:02 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id w2SK9wFO023797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 28 Mar 2018 20:10:00 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 20:10:00 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Mar 2018 20:09:59 +0000
Received: from ([]) by ([]) with mapi id 15.00.1236.000; Wed, 28 Mar 2018 20:09:59 +0000
From: "Richard Backman, Annabelle" <>
To: Bill Burke <>
CC: Mike Jones <>, Roberto Carbone <>, "" <>, Nat Sakimura <>
Thread-Topic: [OAUTH-WG] What Does Logout Mean?
Thread-Index: AdPFuZ82AUZiFFvRRIWVC98G86INvgA7mmyA//+yZICAAI4MgP//m6SA
Date: Wed, 28 Mar 2018 20:09:59 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BA42F798A4E643D99A93D85C6C5AF4AAamazoncom_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: <>
Subject: Re: [OAUTH-WG] What Does Logout Mean?
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Mar 2018 20:10:07 -0000

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 <>
Date: Wednesday, March 28, 2018 at 12:10 PM
To: "Richard Backman, Annabelle" <>
Cc: Mike Jones <>, Roberto Carbone <>, "" <>, Nat Sakimura <>
Subject: Re: [OAUTH-WG] What Does Logout Mean?

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

> 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.