Does OIDC Client token support automatic refresh before the token expires

[Umizhang0910]

Hi, everyone,

Does the token held by TokenRequestState support automatic refresh before expiration, instead of finding the token expires when the request comes, and then requesting IDP to obtain or refresh the token.

Is there any mechanism inside the Quarkus framework that supports automatic refresh of tokens?

Use scenarios

• My usage scenario is that I request another service on the current service. I configured OIDC Client and filter. In theory, when I call the client's method, the requested token will be attached;
• My token is valid for 60 minutes. When multiple requests come in, the token happens to expire, and the request will be blocked until the request IDP gets a new token;
• My requirement is whether the token mechanism of the quarkus framework supports automatic refreshing, when the token is about to expire, rather than when a request comes in

[quarkus-bot[bot]]

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

[sberyozkin]

Hi @Umizhang0910

It is an interesting idea, but I'm not sure it is worth the extra complexity it would bring with it (managing a timer, syncing with the actual OidcClient requests) given that the token refresh occurs once every 60 mins or several days or even longer periods of time, with the most likely case being, that in a highly concurrent application only a few OIDC client requests might need to wait for a few milliseconds, and then all is flowing for another 60 mins, etc

[sberyozkin]

@Umizhang0910 I've decided to open an enhancement request at #46673 to consider it at some point, thanks

[Umizhang0910]

The question is, how, given a rather long typical access token lifespan, does the cost of running and managing the timer compare to a fast token refresh which happens once every 1 hour or whatever the access token lifespan is.

Well, thank you, if the token is valid for a relatively long period, or the token refresh response is very fast, the cost is relatively high compared to running and managing timers. However, it is still necessary for my current usage scenarios, because it takes relatively long to obtain a refresh token and has multiple OCDC Client requirements. If the tokens of multiple Clients expire, it may take up to dozens of seconds to get a response for a front-end request.

[Umizhang0910]

@Umizhang0910 I've decided to open an enhancement request at #46673 to consider it at some point, thanks

@sberyozkin Thank you very much, I hope it can be realized soon.

[sberyozkin]

@Umizhang0910

If the tokens of multiple Clients expire, it may take up to dozens of seconds to get a response for a front-end request.

No, it is not the case since a current request is processed by a specific OIDC client only.

As far as the prioritization is concerned, if you'd like a fast resolution, please consider creating PR.

I think this enhancement won't work for all variations, where custom OIDC client filters can provide request-specific additional parameters required to complete the token acquisition. In general, while I'm positive about this feature being available, the fact that a minor delay occurs once every hour in your case, the actual impact on performance is yet to be evaluated.

Thanks

[Umizhang0910]

If the tokens of multiple Clients expire, it may take up to dozens of seconds to get a response for a front-end request.

No, it is not the case since a current request is processed by a specific OIDC client only.

As far as the prioritization is concerned, if you'd like a fast resolution, please consider creating PR.

I think this enhancement won't work for all variations, where custom OIDC client filters can provide request-specific additional parameters required to complete the token acquisition. In general, while I'm positive about this feature being available, the fact that a minor delay occurs once every hour in your case, the actual impact on performance is yet to be evaluated.

Thanks

@sberyozkin
Uh-huh, what you're saying is right; I didn't describe the case of multiple OIDC clients clearly, which made you misunderstand;

My case is a front-end request coming in to the back-end service, and the current back-end service needs to request several other services that require OIDC authentication to complete the request, so when the tokens of these OIDC clients happen to expire at the same time, each OIDC client filter needs to request the identity authentication service separately to obtain a new token, so in the worst case, the cumulative time may reach tens of milliseconds.

Thanks