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

Fri Jun 14 11:53:41 EDT 2019

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...
> 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...

[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> 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev