Non-reactive TokenValidator

[Spikhalskiy]

Feature description

In recent versions AuthenticationProvider became non-reactive and the reactive version was deprecated.
It would be great to see TokenValidator to become non-reactive too or get an alternative non-reactive version.
Currently, it's not clear if a correct TokenValidator implementation can be blocking. And if it can, why TokenValidator have to return a Publisher.

[sdelamo]

I agree with you @Spikhalskiy we should follow a similar strategy providing imperative and reactive APIs. #1548 #1526

TokenValidator API is reactive because a user may want to do a blocking operation in a token validator. E.g. do a blocking call to the database to verify the API token supplied is valid.

[Spikhalskiy]

@sdelamo yeah, I understand that such a scenario is behind the original thinking of returning a Publisher. What is not clear to me from the docs at least, is it ok to put a blocking IO operation right inside TokenValidator#validateToken call or if this call should return "immediately" with a publisher that should be filled asynchronously with the validation result?

If it's ok to place the blocking code there, in that case returning a publisher is only confusing. The only situation when anyone will use delayed publishing is if they want to optimize the amount of waiting threads.

If it's not ok, it's well aligned with the reactive paradigm. But the fact that #validateToken should never block and is called in the event loop should definitely be in the javadocs. Otherwise, users will put blocking calls inside and return a pre-filled Mono.just(). Which will fly under the radar and lead to hard-to-chase-down degradation and timeouts on request spikes.

[sdelamo]

It is not ok to put blocking code. I think improving the javadoc is a good idea. if you are interesting in contributing such an improvement let me know.

[Spikhalskiy]

@sdelamo Yeah, I will open a docstring PR!