1:59 a.m.
On 29.5.2014 06:38, Bill Burke wrote:
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.
oops, I wrote it
in the opposite side in first sentence:-)
I also meant that ssoSessionIdleTimeout should be bigger than
accessTokenLifespan, which is currently not the case in examples, hence
I wrote this mail. I will send PR for tesstrealm.json bundled in demo
applications also with updated accessTokenLifespanUserAction. If you
want to add more screencasts later, you can change it locally in your
env. Is it ok?
Marek
> 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).