Combining OidcClientRequestReactiveFilter & AccessTokenRequestReactiveFilter

[NMichas]

Hello, I was wondering what's a sensible way to approach the following problem:

I have multiple services communicating with each other using Quarkus Microprofile Rest clients and JWT tokens with propagation (the JWT is generated on my front-end layer and injected in all requests, so I don't need to generate it using OidcClientRequestReactiveFilter). This setup works fine when I have a front-end user interacting with my application; token propagation between services also works fine too.

However, I also have some scheduled tasks. These originate in one of my services at specific time intervals. The problem, obviously, is that a JWT is not available in such case, so as soon as my schedule task tries to contact another service via the MP Rest client it fails with unauthorized.

Question 1:
As per the example on https://quarkus.io/guides/security-openid-connect-client, I could create separate MP Rest clients for each service, using OidcClientRequestReactiveFilter to transparently obtain a JWT for e.g. a default "system" user. However, I have about 15 services (for now) and I'd like to avoid having to duplicate so much code. Ideally, I'd want to be able to somehow combine OidcClientRequestReactiveFilter & AccessTokenRequestReactiveFilter implementing a logic similar to "if a JWT is available, use it, otherwise obtain one for a default user". I understand this is not possible out of the box as per the documentation:

Combining OidcClientRequestReactiveFilter and AccessTokenRequestReactiveFilter on the same REST Client will cause side effects as both filters can interfere with other, for example, OidcClientRequestReactiveFilter may override the token propagated by AccessTokenRequestReactiveFilter or AccessTokenRequestReactiveFilter can fail if it is called when no token is available to propagate and OidcClientRequestReactiveFilter is expected to acquire a new token instead.

Is there something I might be missing here that could help my use case?

Question 2:
As an alternative approach, I could keep all my services annotated with AccessTokenRequestReactiveFilter and then manually create a JWT when my scheduled task starts (e.g. using Keycloak's API). However, how can this JWT be injected into the MP Rest client my schedule task uses?

Thanks a lot for your time and interest in this issue.

[quarkus-bot[bot]]

/cc @pedroigor, @sberyozkin

[sberyozkin]

Hi @NMichas Thanks for describing this scenario. At the moment, I think the 2nd option is the way to go, to get the token injected into the REST client filter run in a scheduled task, @ActivateRequestContext should help, I believe #22477 is relevant, see #22477 (comment), let us know please if it can help

[NMichas]

Thanks for the suggestion @sberyozkin.

Just out of curiosity, I tried to create a Frankenstein filter out of OidcClientRequestReactiveFilter & AccessTokenRequestReactiveFilter :) I did some quick tests and it seems to work as intended, i.e. "if a JWT is available, use it, otherwise obtain one for a default user". Not sure if it introduces any side-effects, I'll test it a little more later on. I attach it here if it's of any use: https://gist.github.com/NMichas/d88d7ac68c2719bbfc437b6272d11d89.

I also realised that I don't need to duplicate all my Rest clients with OidcClientRequestReactiveFilter. All my code that executes without a JWT already present, happens to be designed to start executing by calling a specific service first, so it's enough to only duplicate the rest client of that one service with OidcClientRequestReactiveFilter and keep the remaining Rest clients annotated with AccessTokenRequestReactiveFilter for token propagation. So, that's a good-enough solution for my current use case.

[sberyozkin]

Thanks @NMichas, sounds good, glad you've figured out how to workaround here. I wonder if I can have most of OidcClientRequestReactiveFilter pushed into the abstract filter, I'll have a look

[NMichas]

Yes, @sberyozkin, that's what I tried on the above gist ;)

[sberyozkin]

Hi @NMichas sorry for a delay, I've had a look now at what can be simplified as far as the extension is concerned, and I'm not sure it is needed, I wonder, would it be simpler in your code at https://gist.github.com/NMichas/d88d7ac68c2719bbfc437b6272d11d89 to extend OidcClientRequestReactiveFilter and delegate to super.filter(requestContext) if no propagation is needed

thanks