SSO - checking which user is logged in

maciej.wisniowski

If I have a FA and 2 applications, say X and Y, using SSO, then it is possible that:

User logs In to application X as user1 (SSO session is created in FA and session is created in application X)
SSO session expires in FA (but still persists in application X for user1, so the user is still logged in as user1)
User tries to access application Y and logs in as user2 (different credentials than before) - SSO session in FA is created and the session for user2 is created in application Y

As a result:
The user is logged in to application X as user1 and to application Y (and FA) as user Y.

This is obviously not a desired situation so do you have any clues on how to deal with that?

dan

Hmmm. Why does the user have two different sets of credentials? Is this a privileged user (customer service or something)? That seems kinda weird, but maybe I don't understand the use case.

Can you sync up the session lengths or at least have the FusionAuth session length be longer than the application session lengths?

While I believe the SSO session information is exposed via the JWT API as a refresh token (more here: https://fusionauth.io/docs/v1/tech/core-concepts/users/#user-sessions ) you typically can ignore the SSO session.

maciej.wisniowski

Regarding the use case - we're testing different scenarios and this just appears to be possible to log as a different user in this way.

I can imagine the following real use cases where two or more user credentials sets are in use:

single computer but different users (eg. people working on different shifts or public computers used for training/presentations etc.)
a testing environment where the tester keeps logging in/out as different users

Syncing the session times doesn't seem to be a solution because the application-specific sessions are created when the user accesses these applications. So, unless you log in to all the applications at (nearly) the same time you will not have the session times in sync.

dan

Hmmm. I'm struggling a bit to see what the end goal would be. What would be your desired end state that would solve this (if you could wave a magic wand)?

User would be logged out of App X when they log in to App Y with a different set of credentials?
App Y would not let the user log in with the different set of credentials than App X?
App Y would tell the user "hey, App X has a valid session with user ABC" before they login?
Something else?

I still think you could make the FA SSO session longer than any of the application specific sessions. This would mean that the SSO session in FA would never expire before the session of App X.

maciej.wisniowski

The desired end state for me would be any of these you've brought up but I was wondering about the implementation of the first option (User would be logged out of App X If they're logged in to FA with a different set of credentials).
The possible solution that I was thinking of is sending a request to FA from App X using Ajax or iframe, that will tell me if the user is logged in to FA SSO and what is his current id. This way I'd be able to verify if the current App X user is the same as the FA SSO user and log him out if necessary. Unfortunately, there is no such endpoint in FA and it seems to be a bit overcomplicated so that's why I've asked about the other options.
Of course, another way to deal with it is to leave this as is It is rather not a very common case, but still... it is possible to happen and this poses a security risk of having one user accessing data of another one.

Regarding the session times, even if I have an FA SSO session valid for 12 months and App X session valid for 1 month only it will not solve the issue.
Imagine that after 11 months and 10 days since the FA SSO session was created, the user visits the App X (for the first time in a few months). This will create a brand new session for App X that will be valid for one month (so in this specific case it will last longer than SSO session that expires in next 20 days).

dan

Hiya @maciej-wisniowski

Might make sense to file a feature request. I am not sure how likely we'd be to expose the SSO token to revocation, but we already (I believe) display it in the list of refresh tokens for a user (with an API key).

https://github.com/fusionauth/fusionauth-issues/

I can't think of many workarounds simply because there are two disjoint users (as FusionAuth sees them, because they have different login Ids) and yet you are trying to connect them (so the same human person doesn't login with two different accounts).