Logout notification support

[brockallen]

• ping endpoint for JS to replace check_session (that won't slide cookie?)
• or signalr callback w/ JS library to get notified of backchannel logouts

[brockallen]

We also should have something server-side get calls as a notification as well. Either a service in DI or some event somewhere (on BffOptions?).

[brockallen]

For the record, we have a polling capability for now to ~/bff/user with a ?slide=false option to prevent sliding of the session.

We'll look at adding a push (signalr, SSE, something?) mechanism in a future release.

[dotnetspark]

This is interesting. I can contribute here if you want to.

[damianh]

A push mechanism has some interesting challenges from a scale out perspective needing backplanes etc.

[LilitHakobyan]

Are there any plans to add a session cookie for BFF similar to idsrv.session to be able to detect the logout on a client app without calling bff/user?

[brockallen]

Are there any plans to add a session cookie for BFF similar to idsrv.session to be able to detect the logout on a client app without calling bff/user?

Sorry -- I think your comment slipped thru the cracks. This is an excellent idea. We can think about if and how this might work for a 2.1 milestone. Thanks!

[brockallen]

Are there any plans to add a session cookie for BFF similar to idsrv.session to be able to detect the logout on a client app without calling bff/user?

Question for you on this issue -- is your BFF client using front-channel or back-channel logout notification from your OIDC provider?

[LilitHakobyan]

Are there any plans to add a session cookie for BFF similar to idsrv.session to be able to detect the logout on a client app without calling bff/user?

Question for you on this issue -- is your BFF client using front-channel or back-channel logout notification from your OIDC provider?

No, It's not.

[brockallen]

No, It's not.

Neither?

[brockallen]

Are there any plans to add a session cookie for BFF similar to idsrv.session to be able to detect the logout on a client app without calling bff/user?

Just to follow up here, after more thinking... if the only logout notification to the client is back-channel, then this type of detection mechanism would not work. You need some request from the browser to the backend of the client app (the BFF) so that the server can update/remove/whatever this new session-like cookie would be. So I think the current network polling to ~/bff/user?slide=false is the best approach for now if your client uses back-channel logout notifications. The only improvement here would be a push notification, but that would involve new dependencies (e.g. something like SignalR?), and new JS code, which is currently beyond the scope of the BFF library.

The suggestion you made would work great if the client uses front-channel logout notifications, though. The front-channel logout notification from the browser to the client allows the BFF to emit a response into the browser which could update/remove/whatever this new session-like cookie. Then if the SPA were open in another tab it could do the timer polling to check the in-memory cookie state (again, whatever those details may be).

If your client app does not use either of these, then you'd be on your own to detect the session being terminated. It's possible you could use the check session endpoint itself (again with the timer polling and postMessage to the check session iframe), but that only works in same-site situations, and is again mainly JS you'd have to write. We could consider a sample for this, but it would not be JS that is somehow emitted (and supported) from this BFF library (due to the aforementioned scope constraints). You'd need to use the "bff:session_state" value from the ~/bff/user endpoint claims:

{
    "type": "bff:session_state",
    "value": "mGhXTrySDSXmpQzGuriNTa7dobH1RacKKJYkPpSHzoQ.6D1DC5EE1B334B7C43B17D50AB79D0E9"
  }

[dotnetspark]

@brockallen Just to add more context to back-channel logout notification. BFF can include a background process to check the expiry of the session-like cookie, and if expired push a notification using SignalR. No JS involved. I'm willing to add that behavior if you like.

[LilitHakobyan]

@brockallen I got your suggestions. there was a problem also with multiple tabs, so when in one tab the user performs a logout the other tab stays active until the pooling mechanize will work ( in my case it working in each following minute ) i solve the issue using React Broadcast Channel API basically sending notification from the logout tab to another tab. Also, i have a session extending mechanism based on user activity and using the same API by synchronizing sessions between tabs.
But the case when the session cookies can be deleted directly from the browser is not solved, the application will work until the pooling mechanism will be executed.

[brockallen]

Hi @ylr-research --

Just to add more context to back-channel logout notification. BFF can include a background process to check the expiry of the session-like cookie, and if expired push a notification using SignalR. No JS involved. I'm willing to add that behavior if you like.

Can you elaborate on this, please?

[brockallen]

I think our plan is to provide samples for two of these:
DuendeSoftware/samples#108
DuendeSoftware/samples#109

[dotnetspark]

I can have a BackgroundService for validating the cookie and if expired to push a notification with SignalR

[dotnetspark]

Like this example. I will need to modify some stuff, but you get the idea. If it works, let me know.

[brockallen]

@dotnetspark sorry to pick this up so long from the last time (we were working on the IdentityServer release).

Anyway, back to your sample -- so in short, this is a polling approach on the server, right? There's code to check the server-side session, and when it's expired, the SignalR connection pings the client side code?

[dotnetspark]

No worries @brockallen. Yes! That's exactly the proposal. Does it work?

[brockallen]

Does it work?

It's one way to go about it and I don't see anything wrong with it (but I've not spent any real time thinking about it).

We'd only be able to provide docs with this as a suggestion (and maybe a sample). We'd not be able to implement this as part of our implementation because we'd not want the dependency on SignalR from our library.

[brockallen]

And the more I think about it, this as a sample might get pretty involved pretty quick. How would you do this polling and then lookup of connection in a performant way? I'm guessing there's a bunch of state to maintain, and that's quickly becoming a new product in and of itself :)

[brockallen]

We have an open issue here DuendeSoftware/samples#108 to track working on this sample. Beyond that, I think everything in this issue has been addressed, so I'll close it unless there are other thoughts/comments, or I have missed something.

[dotnetspark]

Makes sense. Thanks!