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

["Richard Backman, Annabelle" <[e-mail]>]

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.

--
Annabelle Richard Backman
Amazon – Identity Services
 
On 3/30/18, 10:42 AM, "Bill Burke" <[e-mail]> wrote:

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