[keycloak-dev] "You are already logged-in" issue

Mon Jul 1 05:58:01 EDT 2019

Added design document 
https://github.com/keycloak/keycloak-community/pull/16 . See here in 
more readable form: 
https://github.com/mposolda/keycloak-community/blob/master/design/authentication-flow-usability.md

Feedback welcomed.

In shortcut, I've tried to add 2 approaches. The "minimalistic" should 
fix the "You are already logged-in" and shouldn't be too hard to 
implement. It doesn't involve any JS tricks, but involves not removing 
root auth session at the authentication finish and support for 
redirecting to the applications instead of showing "You are already 
logged-in" message.

The advanced approach tries to address usability even more. It contains 
the JS tricks and shared authentication session per all browser tabs. It 
overs cases like "Client overriden flow" as well. This will be more work 
and depends on priorities and time if we have time to incorporate this too.

Marek

On 16/06/2019 10:18, Stian Thorgersen wrote:
>
>
> On Fri, 14 Jun 2019 at 17:53, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at 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-a-url-in-different-browsers
>
>     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 at redhat.com
>     <mailto:vramik at 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 at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     >>
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>