Server-side sessions vs. older MvcHybridBackChannel sample

[nikriaz]

As soon as I understand this, a part of older approach in MvcHybridBackChannel sample (LogoutSessionManager.cs, CookieEventHandler.cs) assumes server-side sessions on a client side, while newer approach suggests that now server-side management is available on the IS side, so no need to repeat it on a client.

Would be really cool to get some info how to use this new feature. To be honest don't even know how to start as can't locate any basic concrete information, apart of architecture description. Newer client example with back-channel logout and IS-server-side sessions would be also highly appreciated.

[josephdecock]

Server side sessions in Identity server don't replace server side sessions at your application. The back channel logout mechanism in the sample you link to is still relevant-in fact an identity server server side session's expiration can trigger back channel logout.

The chapter in our docs on server side sessions starts here: https://docs.duendesoftware.com/identityserver/v6/ui/server_side_sessions/, and then continues on child pages discussing how to use it for session management and cross app inactivity timeouts. What questions do you still have after reading those docs?

[josephdecock]

Also, we have a sample of server side sessions: https://docs.duendesoftware.com/identityserver/v6/samples/misc/#session-management-sample

[nikriaz]

Many thanks for the answer! Yep, at first I missed these child pages and samples, thank you. But still IdS-server-side sessions vs. Client server-side versions is still unclear. Indeed, these sessions are different but the list of these sessions (sids) are the same. What's the point to handle separate list of the subs and sids if we already have this well-designed list on IdS? This MVC sample already existed in pre-IdS-server-side sessions era but now I believe we don't need this extra handle anymore.

[josephdecock]

You need a server side session at the application if you want to use a backchannel logout. If you don't do that, and your application session is entirely cookie based, then the only way you can interact with session state is if the cookie is sent, in other words, only on a front channel request. If on the other hand, you have server side session state at the application, then a backchannel request can be sent to the application without ever involving the browser and yet it can still interact with that session state.

[nikriaz]

Finally got what you mean. Basically, we need an application server-side session to have an option to delete it even if the browser is closed. That is the essence of the backchannel logout and this is kind of "fire-and-forget" approach for IdS.

Okay, but the app's cookie should be validated anyway at some point, with both frontchannel and backchannel. That is what your cookie validation extension handler from the sample essentially does - validates cookie against session presence in the session list located in the app. Before the IdS-sessions we obviously need such list. But now, what the reason to validate session against a local list if we can do the same against IdS-server list? In case of "offline logout", from the user standpoint the app behavior is the same - session and local cookie on the user's PC are deleted upon opening browser. Session state is anyway inaccessible (or meaningless) while browser is not involved.

[nikriaz]

I have implemented and tested this approach without app-level list of sessions with such a kind of cookie validator. We even don't have to explicitly care about sid because IdS invalidates refresh token when the session is deleted - as you confirmed in another thread. It works nice as expected and I don't see any operational and architectural drawbacks. Do you?