Open AJO35813 opened 1 month ago
/cc @pedroigor (bearer-token,oidc)
@AJO35813 Hi,
When you use a filter, and you need to force refresh what looks like a valid token to the filter, the only way is to register a custom filter extending the default one and only overriding a single method, isForceNewTokens
, for example: https://github.com/quarkusio/quarkus/issues/41067#issuecomment-2217649551 (you can do something similar) - this effectively causes a new token acquisition.
Let's say the filter sent what it sees as a valid token to the target - but you got 401 because as it happens the token was revoked in the provider. In this case you can probably coordinate via a bean which is injected into this custom request filter, and custom JAX-RS client response filter: the response filter will record in the bean that a refresh is required if 401 is returned and then, when the retry is made, the custom request filter will force the new token acquisition by returning true
. Something along these lines.
Or you can force a new token acquisition after it was used 3 times etc, or even every time.
This will resolve your code example above - the retry goes and the token is renewed.
However, #43417 also makes it possible to set a fixed expiration period, so you don't even have to override anything, just set that property and it will refreshed say every 3 mins.
You can also set a refresh token skew to refresh proactively - so that it is refreshed say if it is within 30 secs of its expiration time - this will guarantee you will never really get a situation where the valid token was sent but got expired by the time it reached the target.
If you prefer you can get a full control, get OidcClient created directly, for example (check OidcClientCreator
), and in case of 401, call its refreshAccessToken
method.
To summarize, the only way to force a refresh of what looks like a valid token at the filter level is to register a simple custom extension filter. You can prevent expiration related errors by doing the proactive refresh.
And alternatively, you can control OidcClient
directly.
Does it address your concerns ?
@sberyozkin What will be the client behavior if both properties are set?
quarkus.oidc-client.credentials.jwt.lifespan= quarkus.oidc-client.access-token-expires-in=
Description
Hello, I'm having troubles with an issue that is quite similar to this one : https://github.com/quarkusio/quarkus/issues/41067 I am using quarkus OidcClientRequestReactiveFilter that is working very good but in my specific case i dont have an expire time returned by sales force so my token is considered always valid. The problem is that this token can expired or revoked and in this case i am getting 401. At first i thought i could catch this 401 error and force refresh the access token but i didnt find a way. All i can do is requesting a new token but it is not propagated into the TokensHelper context so during the next call, it uses the old revoked token (i have retries enabled on my call). It would be nice to have a method that can force refresh the context by requesting a new access token not depending only on the expiration time. Moreover i was wondering if you have an idea of how i could handle this case at the moment?
Here is an example of my calling method :
And my client interface :
Implementation ideas
No response