RestClient with Oidc Token (OidcClientRequestReactiveFilter) is NOT failing when Token is wrong/unauthorized

[spirostz]

Describe the bug

          Given an existing valid realm
          And a failure on token creation (wrong credentials etc.)
          When we call the testClient
          Then Actual url NEVER been called (correct)
          BUT We get valid Response object (not a failure) with status code = 0 (WRONG STATE)

Expected behavior

Expected: Instead, the testClient should fail with an Exception

Actual behavior

We get valid Response (not failure) with status code = 0 (WRONG STATE)

How to Reproduce?

Option 1 --> Run this: https://github.com/spirostz/quarkus-client-oidc/blob/main/src/test/java/org/acme/ClientTest.java

Option 2:

1. Create a Restclient with @RegisterProvider(OidcClientRequestReactiveFilter.class)
2. Make sure that a running keycloak's realm is configured in Quarkus (quarkus.oidc.auth-server-url)
3. Set the token credentials to something invalid eg. quarkus.oidc-client.credentials.secret=wrong_key
4. Inject and call the client, what url you are calling it doesn't matter

Output of uname -a or ver

MINGW64_NT-10.0-22621 spirospc 3.3.3-341.x86_64 2022-01-17 11:45 UTC x86_64 Msys

Output of java -version

openjdk version "17" 2021-09-14 OpenJDK Runtime Environment (build 17+35-2724) OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.6.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

By Using this quarkus.log.level=DEBUG we can actually see the failures from the try to get valid Token

eg 2023-04-06 15:22:12,719 DEBUG [io.qua.oid.cli.run.OidcClientImpl] (vert.x-eventloop-thread-3) Default OidcClient has failed to complete the client_credentials grant request:  status: 401, error message: {"error":"invalid_client","error_description":"Invalid client or Invalid client credentials"}

[quarkus-bot]

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

[sberyozkin]

Hi @spirostz, do you see the following logging message:

https://github.com/quarkusio/quarkus/blob/main/extensions/oidc-client-reactive-filter/runtime/src/main/java/io/quarkus/oidc/client/reactive/filter/runtime/AbstractOidcClientRequestReactiveFilter.java#L46

?

[spirostz]

Hello @sberyozkin,
Propably yes, but that's not the case here. The problem described is that my Rest Client is NOT failing as a consequence to the above oidc error (401 from token creation) or similar token error.

[sberyozkin]

@spirostz Sure, so the filter aborts the flow but you are saying it makes no difference and the main call to the target Quarkus application goes ahead ?
@geoand Hey Georgios, can you please have a quick look (I guess after Easter :-) ? ). I believe the issue can be checked with any test custom client filter which just aborts the response. I can do it with the OIDC tests as well

[sberyozkin]

@geoand sorry, @spirostz has provided a reproducer, I can try with my own tests as well, but yeah, I think the simple client filter aborting the response will do

[geoand]

Cool, let me know if you need me to look into anything

[sberyozkin]

Sure, I'll do a quick test asap and ping you 👍

[spirostz]

Hi @sberyozkin,
I changed the "expected behavior" section. The client should fail with an "oidc token problem" or similar exception (there is nothing to return in that case e.g. 401 error that I mistakenly wrote before)

Also, to answer the last question, No, The actual URL that the rest client is pointing (whatever it is) is NEVER been called but I get a Response object back every time with status = 0 and no data in place.

[sberyozkin]

Hi @spirostz

I think I agree with the idea of propagating the OIDC Client exception if the token acquisition fails, since returning 401 with Response of the aborted request does not tell the client where this 401 came from, it may as well has come from the target endpoint. I'll look into it.

I get a Response object back every time with status = 0 and no data in place.

I believe you should open a new minor issue to track this problem, I propose to open Resteasy Reactive Response status is wrong if the client filter aborts the request or something like that. My fix will remove the code that aborts the request chain directly, so it is worth tracking this issue as well

[sberyozkin]

@spirostz, FYI: #32505