I'd say that's a bug and the access token timeout should take into account
the SSO session max. I wouldn't say it's a high priority though. Access
token timeout is typically minutes while SSO session max is usually
hours/days. Further, there's many other situations where an access token is
not strictly valid even though you can still use it (user/admin remotely
logs out, user is disabled, etc..). If you really really need to be
absolutely sure that an access token times out then reduce it's lifespan
and/or consider invoking the token introspection endpoint to verify it.
On 12 January 2017 at 17:16, Scott Finlay <scott.finlay(a)sixt.com> wrote:
We're having issues that we receive an access token (using our refresh
which appears to be valid for some certain amount of time (based on the
time), but that the session expires in the background some time before that
because SSO Session Max has been reached.
Here's an example experiment:
SSO Session Idle = 2min
SSO Session Max = 3min
Access Token Lifespan = 1min
0 - create session (with client credentials)
---1m00 access token expires---
1m10 - register user (refresh token)
1m40 - register user
---2m10 access token expires---
2m40 - register user (refresh token)
---3m00 session expires---
3m10 - register user DIED HERE
---3m40 access token expires---
4m00 - register user (with client credentials)
Is there any way to make our expires time for access tokens take the
session lifetime into account?
For example, if we request a new access token 10 seconds before SSO
Session Max, it should say
that the token is valid for 10 seconds, not for 60 seconds.
keycloak-user mailing list