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

Bill Burke <> Fri, 30 March 2018 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00175127077 for <>; Fri, 30 Mar 2018 10:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lmUnZGEO9Gyp for <>; Fri, 30 Mar 2018 10:41:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B80DF12704A for <>; Fri, 30 Mar 2018 10:41:27 -0700 (PDT)
Received: by with SMTP id i2so5747081uak.8 for <>; Fri, 30 Mar 2018 10:41:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mexwhlK02hdWHFuCwZ2Yv1KAUVQIJ4KE3btZOchjQOQ=; b=rB+W17cWzHsvorEU/H31Jz23vnxaNr7j/iA23ukZsTB4jsUnUvboGN5PHpOtXHWfd8 GcshB/G63FrnJDs6zU+U+dLYewfvAbSpbQlpA8qT0VasVd3idQfMJjYqVG9gTDn9guqd 8hI6NqcCm3TkMwdf6diyItYVS/cITzSnQocOGGJiLAPDr7qqwH6zRKFU+OshZBdAeXE2 nhF6sf/ohw8Ilb/xeERNiO5e++Vw7fMrvZjPKa/KxzM2oSlmzJiXY+10ZeD40oyOqZIP YlJpXhWtu+jU/89TReCDeu+BR1H1vR8umEYGeHFe5JijMDt3A3u675RWi5ndc4fXFPIG CEiw==
X-Gm-Message-State: AElRT7EDLILFoB2XEUsPoPq1wEn0Gf6pHWewHSOcFbKsRgKsRGDRLG3X LnIeR5MkcmSLlbTwCwNiTIhx6Ocfq56dOtayPMejlA==
X-Google-Smtp-Source: AIpwx4+84QAAM+UK6gYSqS8rJxBbuNsSw8JjCraS3ffVB69W4HshMdX5J0FR/FJrxSW5DCfZZRcbY1CZaXIzsz5XEPQ=
X-Received: by with SMTP id x11mr8307854uah.91.1522431686384; Fri, 30 Mar 2018 10:41:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 30 Mar 2018 10:41:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Bill Burke <>
Date: Fri, 30 Mar 2018 13:41:25 -0400
Message-ID: <>
To: "Richard Backman, Annabelle" <>
Cc: Mike Jones <>, Roberto Carbone <>, "" <>, Nat Sakimura <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 30 Mar 2018 17:41:31 -0000

On Fri, Mar 30, 2018 at 12:57 PM, Richard Backman, Annabelle
<> wrote:
> 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.
> [richanna]
> What does “at boot” mean in the context of OpenID Connect? Do you mean that
> for every logout, the OP makes a Backchannel Logout request to each of the
> client’s node-specific logout endpoints?

Just in case....This is all for backchannel logouts which are out of
band from the browser.

Node boots up and registers with the Auth Server its logout endpoint.

POST /authserver/node_registration


 As I mentioned earlier, the node doing code to token request will
also pass its local session id so it can be associated with the Auth
server's SID.  When an admin initiates a forced logout, a backchannel
logout request is sent to each client's logout endpoint.  If the
client has nodes that have registered, this request is duplicated to
each node.

> If that’s the case, why can’t the
> client make those calls themselves, from whichever host happens to receive
> the Backchannel Logout request?

Your assuming that each node has knowledge of cluster topology which
isn't neccesarily true.  Each additional proprietary extension we've
made is optional.  Nodes can optionally register themselves.  Nodes
can optionally send local session ids with the code to token request.

> Since the client only cares about node-local state, they should be able to
> maintain the mapping between OP session IDs and local session IDs on their
> side.

Considering a cluster of load balanced web applications that dont'
have session replication and don't have knowledge of cluster topology.
The only way for the Auth Server to perform backchannel logout is to
send the same backchannel logout to each and every node.

There's also the case where the nodes do support session replication,
but don't have a way to get at topology or a way to store the
association between the SID and application session id.  In this case
you don't need node registration, but you do need a way to associate
the SID with the local session id.

As a IDP vendor, you have to support all these types of clients.
Telling developers that they are just going to have to manage this
themselves is not really an option if you want adoption.