search

spring-projects / spring-security

Spring Security
http://spring.io/projects/spring-security
Apache License 2.0
8.83k stars 5.9k forks source link

Reactive Security OAuth2 client doesn't propagate traces and baggage's in Spring Boot 3 #14946

Open DaceKonn opened 6 months ago

DaceKonn commented 6 months ago

Describe the bug The current version of Reactive OAuth Security doesn't follow all Observability documentation recommendations, therefore it doesn't propagate trace and baggage's over network. See: Docs Spring.io - 8.4. Propagating Traces

Class example: oauth2/oauth2-client/src/main/java/org/springframework/security/oauth2/client/endpoint/AbstractWebClientReactiveOAuth2AccessTokenResponseClient.java

Where WebClient.Builder() is used statically - therefore it has NOOP ObservationRegistry and doesn't register Request Observations, and doesn't allow propagating traces (for example B3 Brave Zipkin Baggage's propagation).

To Reproduce Creating Reactive OAuth client and trying to send traces and baggage's to authentication server.

Expected behavior OAuth calls from client to server in Reactive Security and Spring Boot 3 start proper request observations and propagate baggage's.

sjohnr commented 6 months ago

Thanks for the report @DaceKonn! I'm not sure I agree with classifying this as a bug, and instead feel this might make a good enhancement request. I don't find anywhere in the docs that we state the OAuth2 Client features support downstream propagation. Do you find anything like that?

Note that you will easily be able to configure a custom WebClient for any OAuth2 Client component in 6.3 (soon to be released) by following Customize the WebClient used by OAuth2 Client Components in the reference (this link currently points to RC1 docs). That section of the docs also includes a more verbose example that works prior to 6.3.

rishiraj88 commented 6 months ago

Thanks, @sjohnr, for taking it into consideration.

DaceKonn commented 6 months ago

@sjohnr Thank you for your response. I might have classified this as bug since "it worked previously" - which is an error on my side. As you stated, you didn't put in the documents any statement that OAuth2 Client supports downstream propagation.

I'm a bit worried how I missed the setWebClient method, but still the required Security Config wouldn't be accepted - too much to override to change one client. The 6.3 example looks a bit better. I know that in my team it will be still frowned upon because of too many beans needing to be declared - but it is much clearer than the "6.3 prior" approach.

Thanks again for your feedback.