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

From: Mike Jones <[email-masked]>
Date: Wed, 28 Mar 2018 13:53:14 +0000

Digital identity systems almost universally support end-users logging into applications and many also support logging out of them.  But while login is reasonable well understood, there are many different kinds of semantics for "logout" in different use cases and a wide variety of mechanisms for effecting logouts.

I led a discussion on the topic "What Does Logout Mean?" at the 2018 OAuth Security Workshop<http://st.fbk.eu/osw2018> in Trento, Italy, which was held the week before IETF 101<https://www.ietf.org/how/meetings/past/101/>, to explore this topic.  The session was intentionally a highly interactive conversation, gathering information from the experts at the workshop to expand our collective understanding of the topic.  Brock Allen<https://brockallen.com/about/> - a practicing application security architect (and MVP for ASP.NET/IIS) - significantly contributed to the materials used to seed the discussion.  And Nat Sakimura<https://nat.sakimura.org/about-me/> took detailed notes to record what we learned during the discussion.

Feedback on the discussion was uniformly positive.  It seemed that all the participants learned things about logout use cases, mechanisms, and limitations that they previously hadn't previously considered.

Materials related to the session are:

  *   Presentation used to bootstrap the discussions (pptx<http://self-issued.info/presentations/What_Does_Logout_Mean_Presentation.pptx>) (pdf<http://self-issued.info/presentations/What_Does_Logout_Mean_Presentation.pdf>)
  *   Notes from the session<https://bitbucket.org/openid/connect/wiki/What%20Does%20Logout%20Mean%3F>
  *   Workshop submission (pdf<http://self-issued.info/papers/What_Does_Logout_Mean.pdf>)
  *   OpenID Connect issue "Create a document explaining "single logout" semantics<https://bitbucket.org/openid/connect/issues/984/create-a-document-explaining-single-logout>"

                                                       -- Mike

P.S. This note was also posted at http://self-issued.info/?p=1804 and as @selfissued<https://twitter.com/selfissued>.

---

From: Bill Burke <[email-masked]>
Date: Wed, 28 Mar 2018 11:18:33 -0400

The biggest problem for us [1] is backchannel logout and we had to add
a lot of proprietary protocols on top of OIDC's backchannel logout
protocol.  Specifically for "traditional" non-Javascript applications
that have multiple endpoints behind a load balancer.   You are really
at the mercy of the application frameworks and infrastructure used to
secure and cluster the application.   If the framework has no way of
invalidating a session across the cluster, then you're forced to
register each endpoint and have the OP make a logout request to each
of those endpoints.  Even if the framework has a way to invalidate a
session across a cluster, the the Session ID is owned and asserted by
the OP.  This means that the application framework has to have a way
to associate the OP's Session ID with a local session.  If there's no
way to do this cross cluster, then you're often forced to fallback to
registering each endpoint and the OP making individual backchannel
logout requests to each RP endpoint.

>From a product point of view, the only viable solution is to front
apps with a security proxy.  Otherwise you're resolving the problem
for each and every application framework you'd provide an
adapter/library for.

[1] https://keycloak.org

On Wed, Mar 28, 2018 at 9:53 AM, Mike Jones <[email-masked]> wrote:
> Digital identity systems almost universally support end-users logging into
> applications and many also support logging out of them.  But while login is
> reasonable well understood, there are many different kinds of semantics for
> “logout” in different use cases and a wide variety of mechanisms for
> effecting logouts.
>
>
>
> I led a discussion on the topic “What Does Logout Mean?” at the 2018 OAuth
> Security Workshop in Trento, Italy, which was held the week before IETF 101,
> to explore this topic.  The session was intentionally a highly interactive
> conversation, gathering information from the experts at the workshop to
> expand our collective understanding of the topic.  Brock Allen – a
> practicing application security architect (and MVP for ASP.NET/IIS) –
> significantly contributed to the materials used to seed the discussion.  And
> Nat Sakimura took detailed notes to record what we learned during the
> discussion.
>
>
>
> Feedback on the discussion was uniformly positive.  It seemed that all the
> participants learned things about logout use cases, mechanisms, and
> limitations that they previously hadn’t previously considered.
>
>
>
> Presentation used to bootstrap the discussions (pptx) (pdf)
> Notes from the session
> Workshop submission (pdf)
> OpenID Connect issue “Create a document explaining "single logout"
> semantics”
>
>
>
>                                                        -- Mike
>
>
>
> P.S. This note was also posted at http://self-issued.info/?p=1804 and as
> @selfissued.
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Bill Burke
Red Hat

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 28 Mar 2018 17:40:47 +0000

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.

--

Annabelle Richard Backman

Amazon – Identity Services

On 3/28/18, 8:19 AM, "OAuth on behalf of Bill Burke" <[email-masked] on behalf of [email-masked]> wrote:

    adapter/library for.

    [1] https://keycloak.org

    --

    Bill Burke

    Red Hat

    OAuth mailing list

    [email-masked]

---

From: David Waite <[email-masked]>
Date: Wed, 28 Mar 2018 12:25:23 -0600

> On Mar 28, 2018, at 11:40 AM, Richard Backman, Annabelle <[email-masked]> 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.

> 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

---

From: Bill Burke <[email-masked]>
Date: Wed, 28 Mar 2018 15:09:11 -0400

On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle <
[email-masked]> 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.
>
>
>
> 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.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 28 Mar 2018 20:09:59 +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?)

From: Bill Burke <[email-masked]>
Date: Wednesday, March 28, 2018 at 12:10 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: Mike Jones <[email-masked]>, Roberto Carbone <[email-masked]>, "[email-masked]" <[email-masked]>, Nat Sakimura <[email-masked]>
Subject: Re: [OAUTH-WG] What Does Logout Mean?

On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Bill Burke <[email-masked]>
Date: Wed, 28 Mar 2018 17:35:00 -0400

On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle <
[email-masked]> 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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 30 Mar 2018 16:57:26 +0000

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

Comments inline.

Date: Wednesday, March 28, 2018 at 2:35 PM

On Wed, Mar 28, 2018 at 4:09 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> 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.
[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? If that’s the case, why can’t the client make those calls themselves, from whichever host happens to receive the Backchannel Logout 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.
[/richanna]
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?
[richanna]
It’s neither. To quote the abstract, it’s “…a logout mechanism….” I think it’s appropriate for the specification to focus on those aspects of the mechnanism that must be standardized in order to have interoperability between OPs and RPs. What we’re discussing falls outside of that, as sticky session implementations are themselves proprietary and the client can address this issue internally without impacting the interoperability of the logout mechanism.

Put another way, the requirement is to get the logout signal from OP to RP. What the RP does with it at that point is up to it.
[/richanna]

--
Bill Burke
Red Hat

---

From: Bill Burke <[email-masked]>
Date: Fri, 30 Mar 2018 13:41:25 -0400

On Fri, Mar 30, 2018 at 12:57 PM, Richard Backman, Annabelle
<[email-masked]> wrote:
> 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

client_id=myclient&
client_secret=geheim&
node=https://node.internal:8443/app/oidc/_logout

 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.

Bill

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 30 Mar 2018 18:47:59 +0000

It sounds like you're asking the OP to provide client-side session management as a service. There may be value in standardizing that, but I think it goes beyond what Backchannel Logout is intended to do.

On 3/30/18, 10:42 AM, "Bill Burke" <[email-masked]> wrote:

    

    client_id=myclient&
    client_secret=geheim&

    

    

    
    Bill

---

From: Bill Burke <[email-masked]>
Date: Sat, 31 Mar 2018 10:15:39 -0400

> It sounds like you're asking the OP to provide client-side session management as a service. There may be value in standardizing that, but I think it goes beyond what Backchannel Logout is intended…

Sure, sort of.  Though, we would have never implemented these
extensions if back channel logout didn't exist as a concept and
requirement.  Its all in the sometimes ugly business of supporting
application developers who have a variety of deployment requirements
and restrictions.

Bill

---

From: Phil Hunt <[email-masked]>
Date: Sat, 31 Mar 2018 18:32:58 -0600

These kinds of discussions are why i think the signal should just be token revoked. It is up to the receiver to infer meaning. 

As soon as we talk in forma like commands(user is to be logged out), a standardized meaning becomes a problem. 

Receiver decision on action based on an issuer signal is the primary difference between a security event signal (a SET) and a security assertion (a JWT) or a command. 

Phil

> On Mar 31, 2018, at 8:15 AM, Bill Burke <[email-masked]> wrote:
>