Implement multiple concurrent sessions

[leastprivilege]

migrated from IdentityServer4

IdentityServer/IdentityServer4#1721

[merijndejonge]

We created an application that supports multiple identities. This seems to work pretty well. A user signs in as Foo at our single instance of identity server and then can access our backend APIs. Then, the user also signs in as Bar to access our APIs under this identity. Our client apps (mobile, web, web extension) allow the user to switch between identity Foo and Bar. The apps maintain the access token for each identity such that the right access token is used when accessing the backend APIs. Also, refresh tokens work fine.

As far as we can see, the only thing that is not working is signout. This is because for signout the session cookie is used to identify the user. However, this cookie always contains the information of the last session (the session of Bar in my example). So, when signing out Foo, actually Bar is signed out. I think this is a known issue because simultaneous sessions are not supported (yet).

My question is twofold:

1. If token refresh works perfectly fine with multiple sessions, what is the problem with also supporting sign out for multiple sessions?
2. As far as we can see and check, the way we deal with multiple sessions just works (apart from the aforementioned sign out), but since multi-session is still not supported by identity server, are we missing something?

Thanks for your help.

[brockallen]

Some research notes. This all looks mostly doable today with all our extensibility points, but intimate knowledge and understanding of how things work is necessary. The things that need to be done are:

• updates to the current IUserSession to understand tracking multiple sessions (e.g. what claim types), sids/client id list (changes to AuthProperties to store diff values indexed on sub), etc.
• a layer over SignIn/SignOut for the UI to AddSession/RemoveSession
• prolly a new select account UI endpoint
• authZ interaction response generator updated to understand multiple sessions and trigger select account UI
• some design on how sub is handled today and if this gets morphed into meaning the identity the user selected on the account selection page. this might also mean that on the authZ response the outbound response needs to clear the "sub" so that subsequent requests re-trigger account selection
• check session JS updates (we'd need to issue multiple sids in the cookie)
• prompt=none handling would likely require the id_token_hint to work properly
• end session request validator to know about checking multiple sessions against the id_token_hint
• maybe updates to some models to express the sub/sid combo that's being logged out (unclear on this one)

So technically all possible today with enough effort. It'd be nice as a first class feature. I don't think we have time for 6.0, but possibly for v6.x (don't know if breaking changes would be required, which would push it to v7).

[pampua84]

Hi, are there any updates regarding this feature?

[brockallen]

Given that it seems possible today with existing extensibility points, we've not been focused on this feature.

[thomas-bingel]

Hi, I am trying to get this to work on IS 6.x. Is there an example on how to realize this feature?

[josephdecock]

Sorry, we don't have an official sample of this feature.

[mtpilarek]

Any progress on this one or at least did someone (maybe you @thomas-bingel) manage to implement it using current extensibility points?

[brockallen]

Nothing new to report. After each release we review all issues in the future milestone, so watch this for any changes.

[dgioulakis]

It is looking like our org and numerous products will need this functionality as well. I'll probably be diving into it soon and exploring how we might be able to achieve this with current Duende extensibility points. Our goal is very similar to how Google provides multiple active sessions and allows you to switch between applications within each user session context.

Will try to remember to report back here any findings that might be useful to others.

[merijndejonge]

See also DuendeSoftware/Support#593:
On top of the Microsoft cookie authentication handler extension points I've created my own session cookie that holds a collection of authentication tickets, one for each session. This collection of sessions gets updated by sign-in/sign-out events triggered by the cookie authentication handler. It seems fairly easy to use this to keep track of sessions.
Not sure about all the use cases you mention (I'm really no expert on OIDC etc), but it seems to me that as long there is a sub/sid available, it must be possible update the authentication tickets in this cookie for different sign-out/sign-in scenario's.

If I can contribute, just let me know. I can for instance share the code for the session cookie with a collection of authentication tickets.

[starlord2048]

Our application needs this functionality as well. I am just wondering whether expressing interest from the community here will influence the priority in the backlog. :)

[dobestar]

We'd be up for this feature also!

[valse]

Hi, we are also facing the same issue with sessions: we store them server-side and if the same user is authenticated in two different browsers even with different client_id, the check session trigger of the first browser sign-out the logged user :
It would be useful to allow multiple sessions for the same user... maybe just for different clients. Thanks!

[walliski]

If I can contribute, just let me know. I can for instance share the code for the session cookie with a collection of authentication tickets.

@merijndejonge we are looking into something similar. Would any of your code/some examples of it happen to be available somewhere online?

[1saeedsalehi]

We would also interested in this feature!