Discussed this with Marek a bit and may have a potential solution here. My suggestion is the following: 1. Add a timestamp to a cookie - this timestamp is updated whenever the user makes any action in the authentication session. Basically submitting any form. 2. Add a piece of JS that reads the value of this cookie. If the value changes it will refresh the page. This will hand over the logic of what to do now to the Keycloak server. If username/password was submitted on one tab, the second tab should automatically update and show the next step (or if complete redirect to the client with successful login)

3. Change the client_id param to a more generic state param. This should be a base64 encoded value with the info that we need in case root authentication session is lost (base64(c=<client-id>&r=(redirect-uri). With having a single param base64 encoded we can more easily add additional info if we need without having to add more query parameters.

4. Root authentication session should not be deleted straight away if there are more child authentication sessions, but rather it should be garbage collected after X mins of inactivity. 5. If root authentication session is garbage collected we should redirect to the client with login error, rather than display error page, with some error message stating failed due to inactivity. The client can then handle it accordingly. On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik <vramik(a)redhat.com&gt; wrote: > Hi, > > I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if > message "You are already logged-in" can be avoided during authentication. > > In current state we discard the RootAuthenticationSession when user > successfully finishes the authentication. In that moment we loose all > the information stored in AuthenticationSession(s) for other tab(s) and > in some cases we do not know where to redirect the user. To solve this > issue there seems to be 2 possibilities. > > 1. Do not remove RootAuthenticationSession once the user finishes the > authentication. Instead we can remove just AuthenticationSession > associated with the specific tab from the RootAuthenticationSession and > the RootAuthenticationSession would be deleted together with last > AuthenticationSession from it. > > 2. Add and pass redirect_uri parameter to login flow. With the parameter > we'd always have an information where it should be redirected in case > the authentication was successfully finished in other tab. > > With solution #1 it'd increase the memory as it keeps > RootAuthenticationSession alive till all tabs are alive. > > Solution #2 keeps current behavior regarding the authentication sessions > but it slightly increases the length of uris. > > wdyt? > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On Fri, 14 Jun 2019 at 17:53, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: Thinking more about this and have some more points inline. Dne 13. 06. 19 v 18:17 Stian Thorgersen napsal(a): > Discussed this with Marek a bit and may have a potential solution here. > > My suggestion is the following: > > 1. Add a timestamp to a cookie - this timestamp is updated whenever the > user makes any action in the authentication session. Basically submitting > any form. > 2. Add a piece of JS that reads the value of this cookie. If the value > changes it will refresh the page. This will hand over the logic of what to > do now to the Keycloak server. If username/password was submitted on one > tab, the second tab should automatically update and show the next step (or > if complete redirect to the client with successful login) So just to clarify, this would also mean that we will track the "authentication state" informations (executions, authNotes, requiredActions etc) per RootAuthenticationSession, not per AuthenticationSession. Correct? Because authentication state will be shared per whole browser, not per individual tabs as it is now. So just the "client state" will need to be shared per individual tabs. ATM I am not seeing any reason why it won't work. But it will require some more refactoring... Yes, we'd need to share the authentication state across multiple tabs > 3. Change the client_id param to a more generic state param. This should be > a base64 encoded value with the info that we need in case root > authentication session is lost (base64(c=<client-id>&r=(redirect-uri). With > having a single param base64 encoded we can more easily add additional info > if we need without having to add more query parameters. I wonder that if instead of just clientId + redirectUri, we can add the parameter, which will contain all the client informations encoded in the JWS token? Something similar/same like current KC_RESTART cookie, which is JWS encapsulating all the client state sent from the OIDC or SAML client. The advantages of this approach: - Less informations on the server side. Especially with the "authentication state" shared globally per rootAuthSession and with the "client state" in the parameter, we "usually" (see below for why word "usually") won't need to track any state on the server side. So we will be "usually" able to remove RootAuthSession directly after authentication finished as it's now. - We will be able to remove KC_RESTART cookie. This cookie is not very great anyway as it encapsulates info just from the single browser tab - Less probability of redirecting to the client with the error as all the client info are available in the token param. Disadvantage: - There are some cases that client info in the JWT will be bigger than 2000 characters limit [1]. In that case, we will need to fallback and will still need to track the client info somewhere else that in the request parameter. Either on server side (hence still a need to have the list of AuthenticationSessions attached to RootAuthSession) or per the cookie, which is not limited in the size. The support for the fallback will require some more refactoring... It's slightly more complicated to keep all state in a JWT, but probably ideal at least when the session isn't too big. Perhaps we could do the fallover thing we discussed in the past. As long as JWT is smaller than 2KB we just add it to a cookie, but if it gets to big we add a reference in the cookie and store the values server side in a session. Would be worth trying to think this one through properly and see if we can solve this once and for all. [1] https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-... Marek > 4. Root authentication session should not be deleted straight away if there > are more child authentication sessions, but rather it should be garbage > collected after X mins of inactivity. > 5. If root authentication session is garbage collected we should redirect > to the client with login error, rather than display error page, with some > error message stating failed due to inactivity. The client can then handle > it accordingly. > > On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik <vramik(a)redhat.com <mailto:vramik@redhat.com>> wrote: > >> Hi, >> >> I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if >> message "You are already logged-in" can be avoided during authentication. >> >> In current state we discard the RootAuthenticationSession when user >> successfully finishes the authentication. In that moment we loose all >> the information stored in AuthenticationSession(s) for other tab(s) and >> in some cases we do not know where to redirect the user. To solve this >> issue there seems to be 2 possibilities. >> >> 1. Do not remove RootAuthenticationSession once the user finishes the >> authentication. Instead we can remove just AuthenticationSession >> associated with the specific tab from the RootAuthenticationSession and >> the RootAuthenticationSession would be deleted together with last >> AuthenticationSession from it. >> >> 2. Add and pass redirect_uri parameter to login flow. With the parameter >> we'd always have an information where it should be redirected in case >> the authentication was successfully finished in other tab. >> >> With solution #1 it'd increase the memory as it keeps >> RootAuthenticationSession alive till all tabs are alive. >> >> Solution #2 keeps current behavior regarding the authentication sessions >> but it slightly increases the length of uris. >> >> wdyt? >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev