OIDC cookies expire time less than refresh token expire time

[canidae]

Question:
Can OIDC cookies expire time be set to refresh token expire time, rather than id token expire time? I believe the answer is "no", so the question really is: Can it be implemented?

Details:
We're using Keycloak as IdP, where we've set id/access token lifetime to the default 5 minutes, but "SSO Session Idle" and "SSO Session Max" (which cause refresh tokens to have the lowest value of these two as expire time) is set much higher (several days in our case).
The problem we've encountered is that Quarkus sets the expire time of the cookies containing the tokens to id/access token expire time plus quarkus.oidc.authentication.session-age-extension (default 5 minutes). Essentially this means that even if the refresh token is valid for days, a logged in user that is idle for more than 10 minutes (5 minutes access token lifetime plus 5 minutes session-age-extension) will have to reauthenticate, even though the refresh token still is valid.
We've solved this by setting a large value for session-age-extension, but it seems like this could've been better solved by setting cookie expire time to match refresh token expire time.

[quarkus-bot[bot]]

/cc @pedroigor (oidc), @sberyozkin (oidc)

[sberyozkin]

@canidae Hi, but the refresh token lifespan is not about the session lifespan, but about refreshing the ID/access tokens, so please add

quarkus.oidc.token.refresh-expired=true

which should be enough if the user has returned just before the session age extension has also expired, and
but better add something like

quarkus.oidc.token.refresh-token-time-skew=5M

That will auto-refresh the tokens once the ID token is within 5 mins of getting expired

(Typing those properties by memory right now, please check, one of them might be in the quarkus.oidc.authentication. namespace)

[canidae]

Heya @sberyozkin. I think you may have misinterpreted the problem. We do have quarkus.oidc.token.refresh-expired=true. The problem is that the cookie saved in the user's browser will with the default settings of Keycloak and Quarkus expire after 10 minutes, even if the refresh token is valid for days. The refresh token is never sent from the browser, thus Quarkus can't refresh the access token.

Edit:
Just to clarify, I don't think this is a bug, merely a confusing behavior for users. With the default settings of Keycloak and Quarkus, users are required to reauthenticate if they've not interacted with Quarkus backend for more than 10 minutes. Even if you increase SSO Session Idle in Keycloak from the default 30 minutes, it will have no impact, because the lifetime of the cookies is set to expire time of id/access token (default 5 minutes) plus session-age-extension (default 5 minutes).
As far as I can tell, the only remedy is increasing session-age-extension, but this probably isn't obvious for users (at least it wasn't for me). This probably is something that should be documented, if making the cookie expire time match the refresh token expire time is not an option.

[sberyozkin]

@canidae

The refresh token is never sent from the browser, thus Quarkus can't refresh the access token.

Right, as it is in the cookie, it is important to make sure the cookie is returned before it has expired, and indeed session-age-extension can help, but it can't guarantee an idle user would not lose these tokens after id token age plus session ext age.
So here having a script in the page pinging some simple endpoint in the background will be enough to ensure that when combined with something like quarkus.oidc.token.refresh-token-time-skew=5M the tokens will be refreshed - I believe I've seen a few users confirming this strategy works.

Am I still missing your question/point :-) ?

[canidae]

Right, as it is in the cookie, it is important to make sure the cookie is returned before it has expired, and indeed session-age-extension can help, but it can't guarantee an idle user would not lose these tokens after id token age plus session ext age. So here having a script in the page pinging some simple endpoint in the background will be enough to ensure that when combined with something like quarkus.oidc.token.refresh-token-time-skew=5M the tokens will be refreshed - I believe I've seen a few users confirming this strategy works.

Am I still missing your question/point :-) ?

I think so, yes :)
It's true that setting a higher session-age-extension certainly won't guarantee that the user won't lose the tokens, but the current defaults guarantees that the user will lose them after 10 minutes of inactivity unless you implement a pinging script (assuming IdP is Keycloak with 5 minute id/access token lifetime, which is the default).

I did come across a recent similar discussion, but it's not the same issue. As long as our users actively caused requests to be sent to the backend, or we set up a pinging script as you suggest, then the users remained authorized and access token was routinely refreshed as expected. Setting refresh-token-time-skew as you suggest and as the linked discussion mentions will help or maybe even eliminate the issue with tokens that expire as long as you repeatedly send requests to the backend before the cookies expire.
I believe there's a better solution to the problem of keeping users authenticated, and that's the issue I'm trying to raise.

By setting a greater value for session-age-extension, there's no need for me to implement a pinging script, nor for users to continuously invoke requests to the backend for tokens to be automatically refreshed. Neither do I need to set refresh-token-time-skew.
By increasing session-age-extension, cookies stored in the browser will have a longer lifespan, and Quarkus will successfully refresh an expired access token, even when the access token expired a long time ago (as long as the refresh token isn't expired).

The whole problem is that with the current default settings, cookies will have a very short lifespan (10 minutes, as mentioned, when id/access token has a lifespan of 5 minutes). When the cookies expire, Quarkus obviously can't refresh the access token.
So my question I feel isn't answered is:
Why isn't cookie lifespan tied to the lifespan of the longer lived refresh token rather than the short lived access token, when Quarkus is perfectly able to refresh expired access token as long as it actually will receive the refresh token?

Setting session-age-extension to match or exceed refresh token lifespan seems to have solved all our problems with users losing their authentication when inactive for more than 10 minutes (technically it could happen after 5 minutes, but that's not an important detail). We no longer need our pinging hacks to keep users authenticated, and whatever lifetime we decide for refresh tokens in Keycloak (essentially this is the setting named "SSO Session Idle") will determine how long an user can idle before being required to reauthenticate. I suspect others also will find that this simple change will solve many of their authentication woes.
We don't have an issue anymore so I'm not looking for a solution. I'm just leaving this comment to address something I think could be handled better by Quarkus (make OIDC cookies lifespan match refresh token rather than id/access token!). And if there's good reasons as of why the default cookie lifespan should match id/access token, well, then perhaps this discussion will help future developers stumbling across the same problem (in that case: Hello future developer! 👋)

I don't think I can explain this in any simpler terms than I've already tried, but in any case I thank you for your time :)

[sberyozkin]

@canidae Thanks, your comment is not separated well so I missed it, thought it was some previous fragment.
Right, it all makes sense, and well explained, by the way, I think pinging to have the auto refreshment is a reasonable technique, but I'm fine if you find it being a bit of a hack :-).

So your proposal is to set the session lifetime to the refresh token lifetime, I haven't thought about it but I'd be cautious about it , because 1) many refresh tokens will be binary, no way to find the exp time 2) Is it really sound by default, I'm not sure about the side-effects.

I can consider adding a boolean property though, if the RT is in JWT format, then use its lifetime for the session cookie - but note if we allow to do it, we'd need to verify its signature, initially, and in cases where a RT grant does not recycle RT, so we'd need to use the RT cookie content. It is feasible but not sure if it is simpler than finding out the RT properties in the provider console and tuning the session age extension accordingly.

That said, having it done automatically might be useful as well, so sure, we can have a look, but I can't prioritize now

Cheers

[allertonm]

@sberyozkin @canidae quarkus.oidc.token-state-manager.split-tokens is enabled, then the refresh token has its own cookie independent of the ID and access tokens.

It seems to me, if tokens are split, the lifetime of each cookie should be driven by the lifetime of the respective token. As things stand right now, even with split cookies, all of the cookies expire based on the ID token lifetime (+ session age extension.)

[canidae]

I see I forgot to mention that we're using split-tokens. Although even without splitting tokens, I'm still curious if the single cookie still could/should have a lifetime of the refresh token.
As I mentioned earlier, setting session-age-extension to match or exceed refresh token lifespan seems to have solved all our problems with users losing their authentication. This is still true to this day, and we've not experienced any side-effects, at least not that I'm aware of.

[sberyozkin]

This background thread in the page can ping the endpoint say every 30 secs or 10 secs, and as soon as the id token will be withing the configured skew, the auto-refresh will happen