[keycloak-dev] Multiple user login on the same browser for Account Aggregation application

Hello, I've used keycloak for such the client application that collect a user's information via API provided by a resource server (e.g. collect balance from bank’s API). If the user has multiple accounts in the resource server, the client application must collect information on all these accounts. In order to do this, the client application let the user conduct an authentication and authorization flow for each account on the same browser consecutively. The current keycloak implementation cannot allow a user to login multiple accounts consecutively and simultaneously on the same browser. Therefore, the user must terminate and restart the browser every time she or he login on one of his or him accounts, which is not good for UX perspective. I’ve opened JIRA (https://issues.jboss.org/browse/KEYCLOAK-9332). I have an idea to resolve it and contribute its realization hopefully. However, I'm not sure this idea is appropriate or not. So, I am happy to get some suggestions and advices on it. [Idea] The current (keycloak-4.8.2.Final) keycloak's implementation seems to be as follows: RootAuthenticationSessionModel class instance has several AuthenticationSessionModel class instances. Browser is bounded to RootAuthenticationSessionModel by AUTH_SESSION_ID Cookie and realm. AuthenticationSessionModel is bounded to Browser's tab by RootAuthenticationSessionModel, client id, and tab id. It seems that keycloak allows a user on the same browser to login on the same account for several clients per browser's tab, and it is good for Web SSO use case. However, it does not work good for Account Aggregation use case. My proposal is that suppressing (expiring explicitly) AUTH_SESSION_ID Cookie and its related Cookies on the client side (not the server side) at the end of an authentication and authorization flow make the browser new to logging-in onto keycloak every time. Also, adding a switch to change the operation mode from the ordinal Web SSO mode to the proposed one (like Securing API mode). Best Regards Takashi Norimatsu Hitachi, Ltd.