quarkus refreshes tokens too late

[swBot]

Hello supporters,
I have implemented a small REST service as a Quarkus (3.13.3/ 3.15.1) application.
This also calls other APIs and has to authorize itself using bearer tokens.
It follows the guideline: https://quarkus.io/guides/rest-client. This means that quarkus itself takes over the token management. And 99% of the time everything is fine.

These tokens are valid for 5 minutes.
The problem is that the service is very busy. It often happens that the end of the token's validity falls exactly on a new request.
In this case, Quarkus does not perform a token refresh, but uses the token again. The counterpart rejects it as expired.

In the documentation I found the property quarkus.oidc.token.refresh-token-time-skew=30S. However, I cannot start my application with it.
The error message appears:

The 'quarkus.oidc.token.refresh-token-time-skew' property can only be enabled for WEB_APP application types

The alternative property quarkus.oidc.token.forced-jwk-refresh-interval=4M does not generate an error when starting - but it also has no effect.

My application is not a web app, so I do not want to set the property quarkus.oidc.application-type=hybrid. Especially since I do not know exactly what its effects are.

As soon as I activate it, the error message

'web-app' applications must have 'quarkus.oidc.authorization-path' and 'quarkus.oidc.token-path' properties set when the discovery is disabled.

appears.

Does anyone have any advice?

[sberyozkin]

@swBot Hi,

The bearer access token can not be refreshed by the endpoint which receives it, only the external client which holds the refresh token can. This is why the application fails to start if you try to enable a token refresh.

Which entity does send this token to Quarkus ?

[swBot]

You are right - it should be a property with the key "oidc-client" and not "oidc". I was confused because of the fact, that this notation is not available in the documentation: https://quarkus.io/guides/security-oidc-configuration-properties-reference
quarkus.oidc-client.refresh-token-time-skew. Unfortunately, setting this property has no effect.

Test-Setup in an isolated environment:

1. set the "Access Token Lifespan" in Keycloak-backoffice to 5 Minutes
2. set the quarkus.oidc-client.refresh-token-time-skew=3M Property in my quarkus
3. send a rest-client-request from my quarkus app to an other app
4. check the keycloak event_entity table --> there is one login event
5. wait 4 minutes an send a second request
6. check the keycloak event_entity table --> there is no new login/token-refresh event (as one might expect from the 3M advance)
7. wait 1 minute an send a third request
8. check the keycloak event_entity table --> now there is a new token-refresh event (counter-test if the setting is not observed)

There is only
quarkus.oidc.token.refresh-token-time-skew. And as I said, this property does not work.

[sberyozkin]

@swBot we have https://quarkus.io/guides/security-openid-connect-client-reference#refresh-access-tokens and https://quarkus.io/guides/security-openid-connect-client-reference#oidc-client shows this property. quarkus-oidc is orthogonal to quarkus-oidc-client both can be used together or independently.

I think I know what may be going on. Some token grants are not allocated refresh tokens. Do you use client credentials by any chance ? In that case you won't get a refresh token - as far as I recall it is not advised somewhere at the OAuth2 or related security considerations doc levels, but you may be able to configure Keycloak to issue it.
Can you check in the logs in response OidcClient gets ? If you don't see the actual JSON, you can register OidcResponseFilter, though it is only available in 3.16.CR1: https://quarkus.io/version/main/guides/security-openid-connect-client-reference#oidc-client-ref-oidc-response-filters

Let me know what you find

[sberyozkin]

@swBot Well, you say you see refresh token events, I'd like to look at a reproducer, can you do the one, you can copy and paste the OIDC client quickstart in Quarkus Quickstarts and update it as needed.
I believe this property is tested and we have had confirmations it was having an expected effect.

Since you have Tokens injected, you can check its isAccessTokenWithinRefreshTokenInterval method before making a call

[sberyozkin]

the check is

final long nowSecs = System.currentTimeMillis() / 1000;
final boolean proactiveRefresh = nowSecs + refreshTokenTimeSkew > accessTokenExpiresAt;

So if the token will expire in 1 min from now, after waiting for 4 mins, this check will produce true, now + 3 mins skew will be after the token expiry date.

It feels like this property is not picked up, make sure it is set in the correct OIDC client tenant, for ex, quarkus.oidc-client.b2b.refresh-token-time-skew=3M

[swBot]

You are a hero!
You found both errors that led me to a dead end.

1. In my head I was working with "oidc-client", but on the documentation pages I was working with "oidc". This meant I excluded the setting quarkus.oidc.token.refresh-token-time-skew and took a wrong turn.

2. I didn't think about the fact that I had to bind it to the tenants.

With quarkus.oidc-client.b2c.refresh-token-time-skew=3M it worked immediately.

Thank you so much for your quick, targeted and competent help. YOU saved my day!
I'm sorry that it was such a stupid error in the end. I assure you that I thought about it for a long time before opening this post.

[sberyozkin]

@swBot Np at all, we are here to help, but also keep improving the docs, :-), thanks for quickly testing all the suggestions, cheers

[swBot]

successfully completed