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

[Bill Burke <[e-mail]>]

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