On 5/28/2014 4:43 PM, Marek Posolda wrote:
Does it makes sense when ssoSessionIdleTimeout has bigger value than
Yes, it makes a lot of sense that ssoSessionIdleTimeout is bigger than
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
? 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
to be something like: "accessTokenLifespan + 5 minutes" instead of 10
minutes to ensure that if people don't set it, it's bigger than
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).
JBoss, a division of Red Hat