[keycloak-dev] Cookies & RememberMe clarification
Bill Burke
bburke at redhat.com
Tue Sep 16 10:15:33 EDT 2014
There are multiple cookies that have different purposes. The remember
me cookie might be a legacy thing that we needed prior to having a user
session. We needed a way to propagate that the user clicked "remember
me" if there was an account action that needed to take place or if OTP
was enabled. This cookie may not be needed anymore because UserSessions
are so core to what we're doing.
We have two keycloak identity cookies. One is persistent, secure, and
HttpOnly and contains a digitally signed access token. This is used to
authenticate a user. The other identity cookie is session only,
non-persistent, can be propagated from Javascript (not HttpOnly) and is
used solely with the Keycloak.js library to determine if the user is
still logged in. (the iframe stuff).
On 9/16/2014 9:52 AM, Marek Posolda wrote:
> On 16.9.2014 12:28, Stian Thorgersen wrote:
>> To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.
> yeah. But besides validity of the KEYCLOAK_IDENTITY cookie, I would say
> that identityToken tight to the cookie should be set to
> ssoSessionMaxLifespan as well?
>
> Fact is that KEYCLOAK_IDENTITY cookie is tight to the UserSession. But
> KEYCLOAK_IDENTITY cookie is refreshed just during SSO login, when
> UserSession.setLastSessionRefresh is called either during SSO login or
> refreshing token. This could lead to the situation when UserSession is
> still valid, but token from KEYCLOAK_IDENTITY cookie is expired, hence
> user is logged out even he has valid UserSession (my example 1 from
> previous mail) .
>
>>
>> With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).
> Maybe yes. My understanding of rememberMe is that you may need to
> automatically login from your browser even after very long time (in
> days), hence I meant to not tight it to UserSession. But maybe it's just
> me:-)
>
> I meant to address stuff like logout of all sessions from acct
> management with the persistent rememberMe records. So when someone wants
> to logout all sessions, it would clear rememberMe records too (Similarly
> when realm.notBefore is set by admin or other similar actions). It would
> be quite amount of work and model, so if we can live with tight
> automatic relogin just to UserSession, it's fine with me.
>>
>> As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.
> ah, ok. So KEYCLOAK_REMEMBER_ME cookie will be used just as a 'hint' to
> prefil login form then? I can add support for this though. As actually
> KEYCLOAK_REMEMBER_ME cookie is not used for anything.
>
> Marek
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 16 September, 2014 12:09:07 PM
>>> Subject: [keycloak-dev] Cookies & RememberMe clarification
>>>
>>> Have few questions related to cookies & rememberMe.
>>>
>>> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
>>> default (so expires when browser is closed). Thing is that lifespan of
>>> the identityToken generated in AuthenticationManager.createIdentityToken
>>> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
>>> cookie is refreshed just during cookie SSO login. So for example when I
>>> have scenario like:
>>> * Login to admin console
>>> * Do some admin work for 15 minutes
>>> * Then click to "Manage my account" button (or to some other Keycloak
>>> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
>>> valid anymore, so I am immediately logged out. Note that UserSession is
>>> still valid as I had couple of refreshToken requests during my 15
>>> minutes 'admin' work.
>>>
>>> So my question is if we can use ssoSessionMaxLifespan for the identity
>>> token instead of ssoSessionIdleTimeout? Note that even in cookie
>>> authentication, we are also checking if UserSession is valid. So if
>>> UserSession is expired, the login won't be successful anyway.
>>>
>>> 2) Second thing is RememberMe feature. Actually we have
>>> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
>>> rememberMe. But this cookie is actually not used anywhere for relogin!
>>> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
>>> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
>>> cookie will survive and you will be able to relogin.
>>>
>>> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
>>> for example if I have scenario like:
>>> * Login to admin console
>>> * Close my browser and wait 15 minutes
>>> * Then open my browser and try to relogin --- ATM both UserSession and
>>> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
>>> work and Keycloak login screen is displayed to me.
>>>
>>> Also scenario like:
>>> * Login to admin console
>>> * Close my browser and restart Keycloak
>>> * Then open my browser and try to relogin --- rememberMe also won't work
>>> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
>>> UserSession provider).
>>>
>>> IMO RememberMe shouldn't be tight to particular UserSession. I would
>>> expect that when I start browser next day, I will be automatically
>>> logged in even if my UserSession from previous day is already expired.
>>>
>>> It seems that to properly support RememberMe, we should use
>>> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
>>> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
>>> privateKey and valid just for one use (Each RememberMe login will
>>> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
>>> This would mean that we will need to persist stuff related to rememberMe
>>> with some additional related informations (realm, user, timestamp,
>>> ipAddress). So for example if admin will set Not-Before for realm, it
>>> will also invalidate all stored rememberMe tokens.
>>>
>>> It seems that this will require some model changes and amount of work,
>>> but ATM RememberMe feature seems to be quite unusable to me.
>>>
>>> wdyt?
>>>
>>> Marek
>>> _______________________________________________
>>> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list