OidcClientFilter produces periodic 401 errors when token expires

[bwand]

Describe the bug
Using the OidcClientFilter leads to some requests failing when the tokens expire. Every time a token expires (eg. every 5 Minutes) we get some 401 Errors from calls annotated with OidcClientFilter.

Expected behavior
OidcClientFilter should refresh the Token before it expires.

Actual behavior
We are getting periodic 401 errors which can also not be solved by using the Retry Annotation. All we can do is to extend the Token expiry time and add a manual retry to every call we have using OidcClientFilter

To Reproduce

1. Create a Client call with OidcClientFilter
2. Let the tokens expire every minute or so
3. Let the system do automated calls eg. 10 calls per second to that Client
4. Watch logfile to see the periodic 401 errors.

Environment (please complete the following information):

• Output of java -version: openjdk version "11.0.2" 2019-01-15
• Quarkus version or git rev: 1.11.2-FINAL

[ghost]

/cc @pedroigor, @sberyozkin

[sberyozkin]

@bwand Refreshing the token itself is tested. Can you clarify please, do you see any refresh confirmations in the log at all ?
Note, Keycloak may have some restrictions about a number of times a refresh token can be used. The latest KC would not even have a RT by default for the client_credentials. I'd appreciate some more info about the cause of 401, thanks

[sberyozkin]

FYI the client will try to acquire a new token, as opposed to refreshing it, if RT is not available - but the repeated token acquisition for the client_credentials may also have the KC level restrictions. I suppose I'd need to add more logging into the client flow

[bwand]

@sberyozkin What we see ist that an application und constant load throws 401 error every 5 minutes in RestClient Calls annotated with OidcClientFilter.
The expiration time for the Tokens in Keylcoak is defaultly set to 5mins. Changing this time does also change the occurance of the 401er.

I cannot see any settings in KC for the number of times a RT can be used....

[bwand]

@sberyozkin What does happen with the Requests where the Token is expired? Will they first get a new one before the call? So is the Token checked every Time before calling?
So maybe this is a timing issue. The token is checked.... it is ok with one millisecond left but when it is checked again during sending the request by the other side it is expired?

I am just guessing....

[sberyozkin]

@bwand In most cases you'd get 401 from the downstream endpoints - if they are under your control then adding a lifespan-grace property would fix it assuming this is the case.
On the client side we can't rewind the chain in case of 401 for a given request. If you can retry once with some delay then may be it can help.
We configure KC with its admin API to ensure, for the oidc client test, the token has been refreshed only once - perhaps it is not configurable at the UI level.

I think what we can do here, is to do something similar to what quarkus-oidc allows for, optionally refresh the token if it will expire within the next few secs or so as configured...

[bwand]

Ok I will give the lifespan-grace config a try... Thanks for the hint.

@sberyozkin How does the client handle the tokens? Does it check "every" time for expiry or does it wait for a 401 from a called service?

Your last suggestion sounds very useful... to check expiry in the next few seconds!!

[sberyozkin]

@bwand As I said it can't rewind the JAX-RS client filter request chain so there is nothing it can do upon a 401 response - it is up to the application to retry if it wants to, as it needs to be able to handle 401 somehow anyway... So yes, it checks the expiry before the call

[bwand]

Hey @sberyozkin your hint with the lifespan-grace works for us. Thank you again for the hint as we did not know this config.

So I leave it up to you if you want to implement your suggestion to make it similar as in quarkus-oidc with the refresh when token will expire in some seconds....

[sberyozkin]

@bwand cool, thanks for the confirmation; yeah, I had it in mind even earlier but the original PR had become too large so I could not squeeze everything :-), I'll keep this issue open until this new option is introduced; it may take a little while as there are other issues I have to deal with as well....