How to extend the user session? / Why does /auth?login=prompt does not extend the session lifetime?

1,414 views
Skip to first unread message

Christian Ciach

unread,
Mar 19, 2020, 8:33:17 AM3/19/20
to Keycloak User
Hello,

we have a desktop application that is using access-tokens to communicate with a server. It is vital for the application that the tokens are always valid, so we go to great lengths to ensure just that.

Of course, the application always automatically refreshes the tokens before they expire. The issue arises when the keycloak-session of the user ends.

Since our update from Keycloak 3.2.1 to 6.0.1 we see that the expire-claims of the access- and refresh-tokens now reflect the end of the user session (see https://issues.redhat.com/browse/KEYCLOAK-4215). While I understand the reasoning behind this change, this change actually is a huge issue for us. Before this change, the access-token was valid for longer than user session, so our servers still accepted the tokens while the user was able to attempt a re-login in parallel, thus creating a new session and new tokens without any interruption of our application. This doesn't work anymore with current versions of Keycloak.

Currently there doesn't seem to be any way to extend the session of the user before the current session has timed out. Because of this, there is no way to ensure that there are always valid tokens available without any interruption. One has to wait for the session/tokens to expire before a re-login creates a new session. If you try to force a re-login of the user by using the parameter "login=prompt", Keycloak asks for the credentials again (as expected) but there is no new session created and the current session is not extended.  (Related issue: There is no way for the client application to know when the user session ends. There is no claim inside the access-token or inside the response of the token-Endpoint that indicates the end of the user session.)

So, my question really comes down to this: How can I ensure that my application always uses valid tokens even when the user-session ends? To make it clear: There is always a user in front of the application, so user interaction can be enforced at any time. If "login=prompt" could be used to extend the session of the user (and if there was a way to tell when the session ends), this issue could be solved by forcing the user to re-login just before the session ends.


Christian Ciach

unread,
Jun 30, 2020, 5:05:53 AM6/30/20
to Keycloak User
I still need help with this.

Also, I've just noticed that i wrote "login=prompt" instead of "prompt=login" throughout my message.

Assuming I would create a Pull Request where a re-login using "prompt=login" would (optionally) create a new user session, would such a PR be considered to be merged? Or are there any strong reasons against this?

Best regards

Pedro Igor Craveiro e Silva

unread,
Jun 30, 2020, 9:18:06 AM6/30/20
to Christian Ciach, Keycloak User
Hi,

Your use case is not 100% clear to me. But did you try using offline tokens?

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/ef18051d-4f56-4702-a4bd-600122844eb5o%40googlegroups.com.

Christian Ciach

unread,
Jun 30, 2020, 12:32:19 PM6/30/20
to Keycloak User
The use case can be summarized as: The user MUST have a valid access token at all times, without interruption. Currently, there is an interruption when the session ends, so we need to find a way to extend/renew the session before the old one expires.

We evaluated the usage of offline-tokens but decided against it, because we still want to force the user to login again every 24h (our configured max session lifetime). But again: There cannot be any interruptions regarding the availability of a *valid* access token, so the user must be able to extend/renew his session somehow. Unfortunately, this doesn't seem possible at the moment. Currently, to extend/renew a session, the user has to wait for his current session to expire (but this invalidates the tokens!). Even when forcing the user to re-enter his credentials using "?prompt=login", the current sessions lifetime won't change.
To unsubscribe from this group and stop receiving emails from it, send an email to keyclo...@googlegroups.com.

Pedro Igor Craveiro e Silva

unread,
Jun 30, 2020, 2:02:15 PM6/30/20
to Christian Ciach, Keycloak User
I see. AFAIK, the user session is updated whenever you try to prompt=login|none (the latter won't ask for credentials but check whether or not the user is authenticated) as well as when refreshing or introspecting tokens.


But again, maybe I'm not still following your problem ...

To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/e0a5e096-9a36-4c76-97d9-d8cd79e42cd5o%40googlegroups.com.

Christian Ciach

unread,
Jun 30, 2020, 2:32:25 PM6/30/20
to Keycloak User
Thank you for your replies so far!

I think you understood the problem just fine, but the code you've linked to actually only resets the "session idle timeout", not the "session max timeout". The user will still be logged out as soon as the "session max timeout" has been reached (24h in our case).

Of course, this timeout is called "max" for a reason, but I think it's reasonable to reset this timeout if the user actually re-enters his credentials.

Pedro Igor Craveiro e Silva

unread,
Jun 30, 2020, 3:56:17 PM6/30/20
to Christian Ciach, Keycloak User
I see now. 

As you said, there are strong reasons for having max respected when configuring a token lifespan.

Another blocker for you is that when using either prompt login or none you won't get the session "re-started" so it will expire and, as you said, your tokens are going to become invalid. And your application will require the user to authenticate again.

One thing I don't understand yet is that if you expect your users to authenticate from time to time, why your application can't live with the session expiring and then obtaining new tokens? Where the session start time could maybe be inferred by your application based on the time when the authentication happened?


To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/03b3cb28-0c13-4b89-bb0b-01e8d75624a5o%40googlegroups.com.

Christian Ciach

unread,
Jun 30, 2020, 4:19:52 PM6/30/20
to Keycloak User
As I said, I want to avoid period of time where the tokens are in an invalid state.

Our application is a legacy java-based desktop client application which uses tons of background threads managed by various components of the application. As soon as the tokens expire, many of these background threads will throw all kinds of Exceptions. Some of those threads are doing time-critical work (like e-trading), so is critical that they not fail. Let's imaging the user is currently on a coffee-break for like 5 minutes. Just in these 5 minutes the session could expire, thus crashing tons of background threads doing time-critical work.

We tried to avoid that by forcing the user to re-login, hoping this would trigger the creation of a new session (and as a result, reset the session-max-timeout). As our session-max-timeout is 24h, we would like to force the user to re-login every 12h our so, so that the session effectively never expires.

I think it's a reasonable assumption that "/auth?prompt=login" would create a new session, because from the perspective of a user it doesn't look any different than an initial login. But in reality, we just need *any* mechanism to ensure valid tokens without interruptions. Using "/auth?prompt=login" for this is just an idea (or call it "wishful thinking") on my part.

Christian Ciach

unread,
Jun 30, 2020, 4:24:59 PM6/30/20
to Keycloak User
Let me also add that the current behavior of "/auth?prompt=login" can lead to a surprising user experience. Let's say an application is forcing the user to re-authenticate using "/auth?prompt=login" just 30 seconds before the session expires. Because the session won't be extended/recreated, the user will have to login again just 30 later. Of course, this will be surprising to the user who will think "What the... Why do I have to type in my credentials again? I just did that 30 seconds ago!".

Pedro Igor Craveiro e Silva

unread,
Jul 1, 2020, 9:14:24 AM7/1/20
to Christian Ciach, Keycloak User
Ah, now that you mention how things work it is more clear :)

And I do think this is very related to what offline tokens try to solve. Your argument for not using it is that you want to force users to re-login but that should not be a problem if you are using offline tokens, right? In fact, we also have token revocation so you can invalidate the client session accordingly and force a re-login whenever you want.

The `iat` claim should also give you an idea when the first token was obtained so that you can calculate how much time remains until the session max is reached.

Out of curiosity, is your application using KeycloakInstalled ?

To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/805323be-7f38-4823-b841-e27d26f21fa1o%40googlegroups.com.

Christian Ciach

unread,
Jul 1, 2020, 10:33:49 AM7/1/20
to Keycloak User
I may need to take another look at offline-tokens. Our IT-department has a very strong opinion against the usage of offline-tokens, but this may be the result of some misunderstandings about them. It is necessary that the user gets logged out after 24h of inactivity.

Maybe I do not fully understand how offline-tokens can be used in our situation, but I will look into that again.

Thank you for the idea to use the `iat` claim as a hint to calculate the end of the session. I didn't think of that.

No, we are not using KeycloakInstalled. Instead, I've written a library from scratch that is very similar to KeycloakInstalled, but conforms to our rather specific internal policies.

Thank you again for all your answers so far! I will take a deeper look at offline-tokens again.

Still, I think it's a bit disappointing that there is no mechanism to avoid the presence of invalid tokens for the short duration between two sessions. But then again, this doesn't seem to be a common requirement.

Pedro Igor Craveiro e Silva

unread,
Jul 1, 2020, 10:46:24 AM7/1/20
to Christian Ciach, Keycloak User
I do think your use case makes sense but at the same time, I'm not sure about all the reasoning behind imposing session max time like that even though the session is being updated during its lifetime. Maybe some flag "Expire when Max" or something that you can set to false and have sessions expiring based on IDLE time ... I don't know.

To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/3eb112c9-a52b-45ee-9a63-7da86c4c929co%40googlegroups.com.

Christian Ciach

unread,
Jul 1, 2020, 11:22:26 AM7/1/20
to Keycloak User
"Expiring on IDLE time" is not enough, because this would allow the user to keep the application open indefinitely without being forced to enter his credentials ever again. We still want the user to authenticate himself like every 24h or so. But currently, re-authentication of the user (by forcing him to enter his credentials) has no effect if the current session is still valid. But waiting for the session to end is no option for reasons mentioned above.

Christian Ciach

unread,
Jul 1, 2020, 11:34:40 AM7/1/20
to Keycloak User
Hera is a fun fact that could be interesting for this discussion:

We didn't had this issue when we were still using Keycloak 3.1.0.FINAL. This is the commit that has lead to our issue: https://github.com/keycloak/keycloak/commit/c055ffb0838b3f7d92169bc2793d2d116f459ac9

Before this commit, the access- and refresh-tokens did not take the session-timeout into account for their `expires`-claims. Thanks to this, all our services still accepted the access-tokens even though the session had expired, because the access-tokens were still valid. This gave our users the opportunity to login again after their sessions expired, while our client-application (with its background threads) kept working, because the access-tokens were still valid.

Of course, the commit makes sense, but for us, it has been nothing but trouble :)
Reply all
Reply to author
Forward
0 new messages