Unable to use @Authenticated with resteasy-reactive and smallrye jwt with proactive auth disabled

[BrainShit]

Describe the bug

I'm not 100% sure if this qualifies as a bug or as a "working as intended".

When you are using resteasy-reactive together with smallrye jwt and turn off the proactive authentication you are unable to use any of the Annotations, @authenticated @RolesAllowed and @permitAll as the log says getting the entity would result in a blocking operation. Meaning that those annotations would become useless.

Expected behavior

Check if the JWT is valid or not actually happening.

Actual behavior

RuntimeException stating
Cannot call getIdentity() from the IO thread when lazy authentication is in use, as resolving the identity may block the thread. Instead you should inject the CurrentIdentityAssociation, call CurrentIdentityAssociation#getDeferredIdentity() and subscribe to the Uni

To Reproduce

Link to a small reproducer (preferably a Maven project if the issue is not Gradle-specific).

Or attach an archive containing the reproducer to the issue.

Steps to reproduce the behavior:

1. Create quarkus application with resteasy-reactive and smallrye jwt
2. Create @authenticated annotated method
3. Set quarkus.http.auth.proactive=false
4. Send a valid or invalid JWT to the endpoint

Configuration

# Add your application.properties here, if applicable.

Screenshots

(If applicable, add screenshots to help explain your problem.)
quarkus.http.auth.proactive=false

Environment (please complete the following information):

Output of uname -a or ver

2.11.2(0.329/5/3) 2018-11-10 14:38 x86_64 Msys

Output of java -version

openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)

GraalVM version (if different from Java)

Quarkus version or git rev

1.12.1.Final

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

Apache Maven 3.6.0

Additional context

(Add any other context about the problem here.)

[quarkus-bot]

/cc @FroMage, @Ladicek, @geoand, @jmartisk, @phillip-kruger, @radcortez, @sberyozkin, @stuartwdouglas

[sberyozkin]

Hi @stuartwdouglas, @geoand, I recall this issue was discussed, but there we had a code manually accessing the injected SecurityIdentity.
In this case I believe the user has JsonWebToken injected - @BrainShit - do you have it injected or do you only use the annotations ?

[BrainShit]

I only use the annotations atm.

[geoand]

Hey @sberyozkin

I personally don't remember anything about this, so anything you and Stuart agree on is obviously fine with me :)

[sberyozkin]

Hey @geonard, there was a discussion at #13835 awhile back, @stuartwdouglas fixed that issue with this commit.

I'm not even sure this issue is specifically related to smallrye-jwt in general since the proactive-auth is disabled and the endpoint is not even expecting JsonWebToken

[stuartwdouglas]

So I don't know what we can do here in terms of a proper fix. We could look for the annotations on the resource and perform authentication if they are found, however this won't help if the resource calls another protected bean.

[sberyozkin]

Hi Stuart @stuartwdouglas that sounds fine, the first resource (or multiple resources accessible directly) in the line is the frontend one so we can say - this is the security wall - anything that follows is not part of this frontend resource security wall (from the point of HTTP level security...). Does it sound reasonable ?