[keycloak-user] Access token appears to be valid even though session has expired in the background

[Stian Thorgersen]

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 at sixt.com> wrote:

> Hi,
>
> We're having issues that we receive an access token (using our refresh
> token)
> which appears to be valid for some certain amount of time (based on the
> expiration
> 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.
>
> Regards,
> Scott
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>