6:06 a.m.
Hi Stian,
Thanks for your reply. It is already spawning some now thoughts. I will try to explain the
underlying problem a bit more.
Unfortunately, this is a single page web app, which additionally is mostly ‘watched’ or
simply ‘looked at’ most of the time (can be hours). Of course the idle timeouts (still
defaults) could be increased, but somehow it felt strange putting the idle time to
something like a day or two (or more). Additionally, the web app opens a websocket to the
backend (standard Javascript web socket). Opening the websocket works fine as long as the
tokens are valid, however, once the tokens are invalid opening the websocket fails due to
security (which in itself is good!). Finally, the web app runs on mobile devices.
Switching the app context (in particular on IOS) for even a second triggers a reload of
the application (bad enough), but also triggers re-authentication, which without the
‘remember me’ functionality always goes past the login page.
What a user expects: as long as the web app is running the login page should not be shown;
if a network problem occurs (they are running around with their mobile devices) the app
has to recover (i.e. re-establish the websocket without the login page); if a user quickly
changes the app context the app should basically continue (at least without the login
page).
One possible solution I think: increase the idle timeouts for the sessions (normal and
remember me) to some very high value (days; which we have tried to avoid so far).
Initially, we tried to use the Keycloak gatekeeper’s ‘enable-refresh-tokens’ feature to
get the token and refresh token updated on the fly with each request (that is our
understanding of this feature), however, it did not work. Tokens were never updated (maybe
we were doing something wrong or there is a bug; this is another open issue on our side to
be followed up). To avoid increasing the idle times to something very long, we are for
moment periodically using the updateToken method to explicitly update the tokens, but even
then, funny as it is, we have to rewrite the kc-access and kc-state cookies (used by the
keycloak gatekeeper) ourselves (not nice as well). Anyhow, in the same way as we found
means to programmatically extend the ‘lifetime’ of the token/updateToken we were thinking
on how to programmatically extend the lifetime of the remember me session.
Thanks & Regards,
Alex
From: Stian Thorgersen [mailto:sthorger@redhat.com]
Sent: 04 January 2019 11:55
To: Alex Chatziparaskewas <alex.chatziparaskewas(a)trapezegroup.com>
Cc: keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] How to update a 'remember me' session?
I wouldn't recommend on having a background keep alive using the update token. Rather,
just rely on the user performing actions to keep the session alive and configure the SSO
idle timeout accordingly to your needs.
With regards to remember me I don't understand your question as there is no difference
here. Remember me only sets a persisted cookie so session survives a browser restart as
well as recently we've introduce options to have different SSO idle and max for
remember me sessions.
On Fri, 4 Jan 2019 at 07:24, Alex Chatziparaskewas
<alex.chatziparaskewas@trapezegroup.com<mailto:alex.chatziparaskewas@trapezegroup.com>>
wrote:
Hi All,
We are using the keycloak javascript adapter. In the same way as the token and refresh
token can be updated gracefully in the background using its updateToken method, is there
any means by which the same can be done to a 'remember me' session?
Thanks & Regards,
Alex
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user