On 5/28/2014 4:43 PM, Marek Posolda wrote: > Does it makes sense when ssoSessionIdleTimeout has bigger value than > accessTokenLifespan? Yes, it makes a lot of sense that ssoSessionIdleTimeout is bigger than accessTokenLifespan. Access token lifespan is supposed to be short as the sso session may have been invalidated by the admin, a role may have been changed, an application or user may have been disabled, etc... The refresh token request is really a check to see if any of those events happened.

> To me not, as if accessToken expires then > refreshToken might be already outdated as lastSessionAccess is updated > during refreshing token. > Access token timeout is supposed to be much less than ssoSessionIdleTimeout. There is no more refresh token timeout. It has been replaced with ssoSessionIdleTimeout and ssoSessionMaxLifespan. > I wonder if we should update timeouts for the realm used in examples > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/t... > ? Currently accessToken timeout is 50 minutes but ssoSessionIdleTimeout > is not specified, so it has default value 10 minutes. Also > accessCodeLifespanUserAction has 100 minutes, which is quite big. wdyt? > Yes we need to change the demo code. The large access token timeout in the demo is just legacy. It is so large because we used to not have refresh token support. Neither did we have any user session management. The accessCodeLifespanUserAction is so large because I found when doing presentations on Keycloak (and the screen casts) I might talk so long in between actions, the access code would time out. That is why it is 100 minutes. And the only reason why. > I also think if we should change default value of ssoSessionIdleTimeout > to be something like: "accessTokenLifespan + 5 minutes" instead of 10 > minutes to ensure that if people don't set it, it's bigger than > accessTokenLifespan. > I think the defaults are good as they are. But the demo.json file needs to change to reflect the defaults (or just be left blank).