Increase default OIDC session-age-extension to minimize chances of dropping expired ID tokens

[sberyozkin]

This PR is really only about improving an OIDC authenticated user experience than fixing anything OIDC specific, following several discussions with users, the last one being with @calvernaz a few weeks back related to a difficult to trace issue with #41015.

So, the OIDC session cookie serves the only purpose: keep an ID token (directly in the encrypted form or indirectly via a reference to some custom token state manager's state) and make it available to Quarkus whenever an already authenticated user tries to access Quarkus again, for OIDC be able to analyze this ID token: confirm it is valid, refresh if it has expired or redirect the user to a session expired page in order to explain to the user that the session has expired.

If the session cookie has expired, then the browser drops it and Quarkus does not know that the current user authenticated and therefore must treat it as a new request and redirects the user to OIDC provider to authenticate.

It leads to a rather poor user experience. For example, imagine you have authenticated to an airline's website, stayed idle for a bit longer that than the session age is, now you click on your order and you see a request to enter name and password at the SSO OIDC provider login page, without any explanation.

So extending the session cookie's max-age to a few hours by default simply minimizes the chances of the expired ID token being dropped together with its session cookie container and thus giving OIDC a chance to do something about this expired ID token - for example, auto-refresh it if the token refresh is allowed, or, redirect the user to a session expired page where a user can be explained the sessin has now expired, and offered a link to re-authenticate.

Also, extending the session cookie's max-age does not change the real user session's age, that of the ID token.

Fixes #41130.

I've set to 5 hours by default but it can probably be set to 8 hours or more at a later stage. Users can tune it further as needed, this PR is about trying to help users avoid having to set this property in real prods, since without it, the expired ID token is always lost and users would see re-authentication screens without any hints as to what has happened.

CC @calvernaz

[sberyozkin]

Sorry, forgot to check oidc-wiremock tests which actually compare the age of the session cookie with the age of the ID token which this cookie keeps encrypted. These tests confirm that by increasing the session age extension, it is the session cookie age which is increased, the real session age, ID token's age, remains the same.

I.e, if the session cookie age is bigger than the ID token's age by a few hours then if the user remains idle for longer than the token's age but still less than the session cookie's age, the chance of Quarkus seeing this expired ID token and doing a useful action with it increases

[sberyozkin]

We have agreed with @pedroigor to avoid changing the default session-age-extension property to avoid even slightest security concerns, esp if the session cookie encryption is turned off.
I'll revert the property update but keep the doc updates as they make it now much clearer how users can manage this property if they require it

[sberyozkin]

Hi Pedro @pedroigor, after thinking more about it, I've tried to rework it, instead of increasing the max-age by 5 hours no matter what. Essentially keeping it nearly exactly as it is currently on the main branch, where the cookie max-age is increased with this property value only if the refresh token is required and the RT is present and I added extra check if the session expired path is available.

The only impactful change is that it is an optional 1 hour extension, instead of 5 mins. 1 hour appears to be the bare minimum to me if users enable the token refresh. They will certainly have to set this property manually otherwise in this case.

Hopefully an 1 hour optional extension (only if the user wants the token refresh or session expired page redirect to work) is all right, compared to the previous attempt of a 5 hours extension in all the cases...

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 33564d7.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 33564d7.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.