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

Bill Burke <bburke@redhat.com> Wed, 28 March 2018 21:35 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 8E8301273E2 for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 14:35:04 -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 XSLnUN3PFf9f for <oauth@ietfa.amsl.com>; Wed, 28 Mar 2018 14:35:02 -0700 (PDT)
Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) (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 2DF2D127337 for <oauth@ietf.org>; Wed, 28 Mar 2018 14:35:02 -0700 (PDT)
Received: by mail-ua0-f180.google.com with SMTP id u9so2445424ual.13 for <oauth@ietf.org>; Wed, 28 Mar 2018 14:35:02 -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=fW4beA6THzJ6STXcxbBT4i8PVMrZ31hHVFeSQmB4mQ4=; b=P1JfuBK3nDnSmO0jovE+iZWRQGKA/lHudFw/Pykw2zfyQtQBOBnEHhl5F9peacCLVr LfI7f5AL0Nc8jBFLOqTdYWlp+y2BEY3D70nVYMTemqvHp9yTDJX/qlju2UD0tQergA+l GXOdpON1bezgWKGsDfH6ooIyw7fAcXbibqe2EBxhcBnsV+m7vMILo9gaSgrk/d/1VUcN T8uZRQpQPkMX1yDJNMhZTY00MO+mvX7SilsmfzJp1nWJTQ/Tt8TPbYmdq9vYQrYnpBAM PYBHIpVXL2sB6Qyv/luOjevkWcJN7kpRYahe+YQyGahBwwDTkwwi5VuT3Ak5a4nGyaY0 9oUQ==
X-Gm-Message-State: AElRT7FiOfknUafnMp6QfF0h7HndQPoSJ6lLajy0cmWTfaHHge5hambd tcI3rY8Xiuob5nh7ch+KJv9deBMthc9nm0jKpe+/yQ==
X-Google-Smtp-Source: AIpwx4+RaY8WT4lbleTP11NTA6MLL7oULV7TGiF0TOS5CYhT3Ai6lyulSSuwq0rcXl+HMGg1RnQ1qle/0+sBL3y6MIs=
X-Received: by 10.159.37.133 with SMTP id 5mr3785598uaf.1.1522272901092; Wed, 28 Mar 2018 14:35:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.13.199 with HTTP; Wed, 28 Mar 2018 14:35:00 -0700 (PDT)
In-Reply-To: <BA42F798-A4E6-43D9-9A93-D85C6C5AF4AA@amazon.com>
References: <DM5PR00MB02932B889807DF883C006512F5A30@DM5PR00MB0293.namprd00.prod.outlook.com> <CABRXCmykJMcy-PdapRURd7YuZxfMbD9dHkf89AKxObM_2bAqKQ@mail.gmail.com> <9A072F0C-96A0-4F5C-8FD0-76110AA2FA3E@amazon.com> <CABRXCmy6aUO_1=Sp08U=B2mV22oP96-R9t16sDsZbo0vDX6fnQ@mail.gmail.com> <BA42F798-A4E6-43D9-9A93-D85C6C5AF4AA@amazon.com>
From: Bill Burke <bburke@redhat.com>
Date: Wed, 28 Mar 2018 17:35:00 -0400
Message-ID: <CABRXCmxWaU8741R8ux2JAo+LmaLsr+Rh=XADLeyV=7cCjqsokQ@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="001a1142966c8573c705687fc707"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nVtD90cN_iI1KUWl2cKbQuglc3U>
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 21:35:04 -0000

On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle <
richanna@amazon.com> wrote:

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

FWIW, our OP implementation allows RPs to register their node specific
logout endpoints at boot.  This request is authenticated via client
authentication.  We also extended code to token request to transmit the
local session id.  The OP stores this information.  Backchannel logout
POSTS to each and every registered node and transmits a JWS signed by the
OP containing the local session ids to invalidate.  That's been enough to
cover all the weirdness out there so far.


> 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?)
>
>
>

Then,isn't any backchannel logout specification more of a framework than an
actual protocol?


-- 
Bill Burke
Red Hat