How to specify refresh tokens lifespan in Keycloak

by

As pointed out in the comments by @Kuba Šimonovský the accepted answer is missing other important factors:

Actually, it is much much much more complicated.

TL;DR One can infer that the refresh token lifespan will be equal to the smallest value among (SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max).

After having spent some time looking into this, and now looking back at this thread, I feel that the previous answers felt short to explain in detail what is going on (one might even argue that they are wrong actually).

Let us assume for now that we only have SSO Session Idle and SSO Session Max:

  • and SSO Session Max > SSO Session Idle in this case the refresh token lifetime is the same as SSO Session Idle. Why? because if the application is idle for SSO Session Idle time the user gets logout and that is why the refresh token is bound to that value. Whenever the application requests a new token, both the refresh token lifetime and SSO Session Idle countdown values will be reset again;
  • and SSO Session Max <= SSO Session Idle then the refresh token lifetime will be the same as SSO Session Max. Why? because regardless of what the user does (i.e., idle or not) the user gets logout after SSO Session Max time, and thus why the refresh token is bound to that value.

From here we conclude that the refresh token lifespan is bound to the lowest of the two values SSO Session Idle and SSO Session Max.

Both those values are related to Single Sign-ON (SSO). We still need to consider the values of the Client Session Idle and Client Session Max fields of the realm settings, which when NOT set are the same as SSO Session Idle and SSO Session Max, respectively.

If those values are set, in the context of the refresh token, they will override the values from SSO Session Idle and SSO Session Max, BUT only if they are lower than the values from SSO Session Idle and SSO Session Max.

Let us see the following examples: SSO Session Idle = 1800 seconds, SSO Session Max = 10 hours and:

  1. Client Session Idle = 600 seconds and Client Session Max = 1 hour. In this case, the refresh token lifespan is the same as Client Session Idle;
  2. Client Session Idle = 600 seconds and Client Session Max = 60 seconds. In this case, the refresh token lifespan is the same as Client Session Max.
  3. Client Session Idle = 1 day and Client Session Max = 10 Days. In this case, the refresh token lifespan is the same as SSO Session Idle;

So in short you can infer that refresh token lifespan will be equal to the smallest value between (SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max).

So the claim from previous answers that you can simply use the Client Session Max to control the refresh token lifespan is FALSE. One just needs to look at the previous examples 1) and 3).

Finally, the fields Client Session Idle and Client Session Max from the realm settings can be overwritten by the Client Session Idle and Client Session Max in the clients themselves, which will affect the refresh token lifespan for that client in particular.

The same logic applies but instead of considering the values Client Session Idle and Client Session Max from the realm settings one needs to consider those from the client advance settings.

More Related Contents:

  1. Why Does OAuth v2 Have Both Access and Refresh Tokens?
  2. What is the purpose of a “Refresh Token”?
  3. Does OpenID Connect support the Resource Owner Password Credentials grant?
  4. How to refresh token with Google API client?
  5. How can I revoke a JWT token?
  6. Google Home Authorization Code and Authentication with Google Account
  7. How does OAuth 2 protect against things like replay attacks using the Security Token?
  8. Oauth 2.0 authorization for LinkedIn in Android
  9. Using Postman to access OAuth 2.0 Google APIs
  10. Gmail API returns 403 error code and “Delegation denied for “
  11. Difference between OAuth 2.0 “state” and OpenID “nonce” parameter? Why state could not be reused?
  12. Error: invalid_request device_id and device_name are required for private IP
  13. Sign in with Google temporarily disabled for this app
  14. 403 Forbidden message when calling the v3 Google Calendar API using a Service Account via OAuth 2.0
  15. Should I explicitly send the Refresh Token to get a new Access Token – JWT
  16. “This app would like to: Have offline access” when access_type=online
  17. Is it possible to be able to correctly select any available Google account to use when using authorisation via the JS client library for Drive?
  18. How to bypass entering authentication code to authorize my code everytime I use the YouTube Data API v3
  19. Google APIs Console – missing client secret
  20. Using Oauth tickets across several services?
  21. Keycloak and Spring Boot web app in dockerized environment
  22. Using OpenID/Keycloak with Superset
  23. What’s the difference between OpenID and OAuth?
  24. Keycloak retrieve custom attributes to KeycloakPrincipal
  25. Adding http headers to window.location.href in Angular app
  26. Sending email via Gmail & Python
  27. client secret in OAuth 2.0
  28. keycloak Invalid parameter: redirect_uri
  29. Access to Google API – GoogleAccountCredential.usingOAuth2 vs GoogleAuthUtil.getToken()
  30. How to get Keycloak users via REST without admin account

Leave a Comment