Few tips: - If you enable "Remember me" for the realm, the KEYCLOAK_IDENTITY cookie won't be cleared at the end of browser session. - There is callback "onTokenExpired", which you can use in keycloak.js adapter when the accessToken is expired. You will be redirected back to Keycloak server and re-logged with SSO (as long as KEYCLOAK_IDENTITY is still valid). The approach with "token" may work, but I would personally use the approach with shorter token timeouts and redirect to the SSO, assuming that rememberMe will work. This has some downsides (redirect to the Keycloak needed periodically, rememberMe available), so not sure if it works for you. If you want the approach with "token", you may need to disable session iframe in that case (as the SSO session on Keycloak side may not be longer valid after browser restart). Marek Dne 4.2.2018 v 14:48 Ori Doolman napsal(a):

Marek, Thank you very much for that answer. Seems that 'remember me' feature was exactly what I needed. So simple... :) Thanks, Ori Doolman Lead Software Architect Amdocs Optima +972 9 778 6914 (office) +972 50 9111442 (mobile) [cid:image001.png@01D2C8DE.BFF33E10] From: Marek Posolda [mailto:mposolda@redhat.com] Sent: Monday, February 5, 2018 10:19 To: Ori Doolman <Ori.Doolman(a)Amdocs.com>; keycloak-user(a)lists.jboss.org Subject: Re: [keycloak-user] keep login state after closing browser Dne 5.2.2018 v 09:18 Marek Posolda napsal(a): Few tips: - If you enable "Remember me" for the realm, the KEYCLOAK_IDENTITY cookie won't be cleared at the end of browser session. - There is callback "onTokenExpired", which you can use in keycloak.js adapter when the accessToken is expired. You will be redirected back to Keycloak server and re-logged with SSO (as long as KEYCLOAK_IDENTITY is still valid). The approach with "token" may work, but I would personally use the approach with shorter token timeouts and redirect to the SSO, assuming that rememberMe will work. This has some downsides (redirect to the Keycloak needed periodically, rememberMe available), so not sure if it works for you. If you want the approach with "token", you may need to disable session iframe in that case (as the SSO session on Keycloak side may not be longer valid after browser restart). One thing, I am not 100% sure if you need to disable session iframe if you want to use "token" approach. Just a tip, that it's maybe a reason why it doesn't work for you, but don't know for sure. Marek Marek Dne 4.2.2018 v 14:48 Ori Doolman napsal(a): Hi, My web application is using the Keycloak JS adapter, and I'm using the 'implicit' flow for getting the access token. I have a requirement to prevent the user from keying again passwords for 24 hours (assuming the token is expired after 24 hours), even after browser is closed and re-opened. There is a cookie called 'KEYCLOAK_IDENTITY', which I assume preserve the login state, but it is a session cookie and it is deleted after closing the browser window. I also see that in the initOptions of the adapter, I can pass an existing access token by the 'token' property. Hence, I was thinking to persist the 24hours access token into localStorage and then read it and pass as part of initOptions to the adapter when my application starts. However, I cannot make it work and I'm not even sure this is possible to do so. Is it possible to use the 'token' initOption like that? If not, is there a recommended approach for implementing such requirement ? Thanks, Ori Doolman Lead Software Architect Amdocs Optima +972 9 778 6914 (office) +972 50 9111442 (mobile) [cid:image001.png@01D2C8DE.BFF33E10] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer><https://www.amdocs.c... _______________________________________________ keycloak-user mailing list keycloak-user@lists.jboss.org<mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>