Quarkus OIDC: Session invalidated when ID token expires?

[cattoMarco]

Hi everyone,

I’m using Quarkus with OIDC and I’m struggling with the expiration of the ID token.

In my case, I must use an Identity Provider that returns the ID token only after the initial login, but it cannot be refreshed using the token endpoint (a request to the token endpoint with grant_type=refresh_token returns only the access_token and refresh_token).

When the ID token expires, the user session is invalidated and the user is redirected to the login page. Because of the IdP configuration, this login requires a new OTP, so the redirect is visible to the user and disrupts the experience.

I tried adjusting some Quarkus OIDC properties to make the application not depend on the ID token, but I couldn’t achieve the desired behavior.
Here is an example of my configuration:

quarkus.oidc.auth-server-url=https://localhost:9031/
quarkus.oidc.client-id=ac_oic_client
quarkus.oidc.credentials.secret=
quarkus.oidc.application-type=web-app
quarkus.oidc.token.refresh-expired=true
quarkus.oidc.token.refresh-token-time-skew = 59
quarkus.oidc.authentication.id-token-required=false
quarkus.oidc.authentication.user-info-required=true
quarkus.oidc.authentication.scopes=profile,email
quarkus.oidc.token-state-manager.split-tokens=true
quarkus.http.auth.permission.authenticated.paths=/
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.oidc.authentication.pkce-required=true
quarkus.oidc.authentication.java-script-auto-redirect = true
quarkus.log.level=DEBUG

I also tried setting quarkus.oidc.token.refresh-expired=false and removing quarkus.oidc.token.refresh-token-time-skew, but the problem persisted.

According to the OpenID specification, an IdP is not required to return a new ID token on refresh — but I’m not sure if Quarkus has any specific restrictions or assumptions related to this behavior.

I also checked this discussion: #29061, but I couldn’t find anything that helped in my case, and I wasn’t sure if it was appropriate to continue that conversation.

Does anyone have any ideas or suggestions on how to handle this scenario?

This is my first discussion on this project, so if something is missing or misplaced, please let me know and I’ll update or move it accordingly.
If you need any additional details about my setup or configuration, I’ll be happy to provide them.

Thanks in advance!
Marco

[quarkus-bot[bot]]

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

[sberyozkin]

Would it be possible to implement an optional behavior where Quarkus automatically generates a new ID token when the current one has expired and cannot be refreshed by the provider?
That would help avoid unnecessary re-authentications in scenarios like this, while still keeping the feature optional for compatibility reasons.

Right, I think we can add a property to let users do it, the reason I'd like to keep it optional is that it should be a user opt-in, there is no continuation in the ID token issued by the provider subsequently replaced by the RS generated ID token.

FYI, in general, we only have these internal ID tokens generated to support a common OIDC flow in the code which works with OIDC providers and requires ID token in various places including the session max age calculation, but when logging in into OAuth2 providers that do not issue ID tokens.

However, I guess if you can get the required info from UserInfo then we can indeed allow this transition from the real but expired ID token to the internal generated one. Customizing this process is not possible.

[cattoMarco]

Thanks again for the detailed explanation. I fully agree with your reasoning for keeping the behavior optional and requiring explicit user opt-in.

I just have one additional question to understand the current situation better:
Is there any way, with the current version of Quarkus, to automatically generate such an internal ID token when the provider-issued one expires, or is this only possible once a new feature is implemented?
From what I understand, it seems this behavior isn’t currently achievable through configuration or extensions, but I want to make sure I’m not missing any workaround.

Also, please let me know if I should open a separate feature request (or enhancement issue) specifically for this functionality.

[sberyozkin]

@cattoMarco Hi, as I said in the previous comments, a workaround is not possible, but I'm working on a fix right now. I'll open an issue shortly. Also, I think no extra property is required because a user already opts in by saying id-token-required=false, i.e, a user already confirms that the application does not really care if the provider issued ID token or not. I think it is a bug that a token is not auto-generated in your case

[sberyozkin]

@cattoMarco FYI, #51064

[cattoMarco]

Perfect! Thanks!

[sberyozkin]

Thanks for raising this issue, @cattoMarco