I'm going to describe the bug as I understand it happens:

Tomcat runs 3 applications, all of which require a session and are unified in a SSO session.

Define 3 apps:
API - the api
ROOT - creates a session and just redirects to the front
FRONT - handles the frontend

1. User logs in and receives all of the session cookies including the SSO cookie.

2. User doesn't use the app for a while and the SSO cookie expires, which redirects to the login page.

3. ONLY the SSO session is invalidated in the client-side and that is the only session that gets deleted for the client.

4. When accessing the login page, the user accesses the API and the FRONT apps which results in them getting a new session for those. User doesn't access the ROOT app and doesn't get a new session for that app (still has the old session)

5. User tries to login and gets a 408 request timed out because he is trying to login with j_security_check using an already invalidated ROOT session.

I can't think of a single reason, that when the SSO session is invalidated, why not invalidate all of the session which make up that SSO session (in the client side).

Why let the client side keep the session cookies for the other sessions when the SSO one is invalidated. 

I do understand that the user just needs to send a request to any of the apps to receive a new session and I resolved this by just adding a fetch() call to that app. But I still can't think of a reason that tomcat doesn't tell the browser to invalidate all of the sessions which corelate to that SSO session.

Would love some clarification and a possible fix?