Proactive auth as false doesn't work for endpoints annotated with @PermitAll and requests with Bearer Token

[jrepe]

Describe the bug

I was moving a service we have from Quarkus version 2.3.1.Final to 2.7.1.Final and I've noticed there's different behaviour when it comes to proactive authentication and bearer tokens. From version 2.4.0 onwards, setting quarkus.http.auth.proactive=false doesn't seem to influence requests with bearer token authentication when the endpoint the request targets is annotated with @permitAll, returning 401 instead of 200, as was the case before 2.4.0. I've used Postman and curl for testing and additionally, the reproducer has tests that also produce different behaviour depending on the Quarkus version.

This is the endpoint I'm testing

@PermitAll
@Path("/hello")
public class GreetingResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello RESTEasy";
    }
}

application properties:

quarkus.http.port=8080
quarkus.http.auth.proactive=false

Is this change in behaviour expected and does Quarkus treat the @permitAll annotation differently than it did in the versions prior to 2.4.0? I'm trying to understand the change in this behaviour, if it's expected or not, so I can modify our application code if needed.

Expected behavior

Request with Bearer Token authentication header to an endpoint with @permitAll annotation should succeed when proactive authentication is set to false, as was the case in version prior to 2.4.0.

Actual behavior

Request fails with 401.

How to Reproduce?

Reproducer:
https://github.com/jrepe/quarkus-proactive-reproducible

Steps to reproduce:

1. Set Quarkus version to 2.3.1.Final and run tests (All tests should pass)
2. Set Quarkus version to 2.7.1.Final and run tests (Bearer Token test should fail)
3. Remove @permitAll annotation from GreetingResource in GreetingResource.java, run tests again
   (All tests should pass)

Output of uname -a or ver

Darwin Kernel Version 21.1.0: root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64 i386 MacBookPro16,1 Darwin

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

2.7.1

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

Gradle 7.3.3

Additional information

No response

[quarkus-bot]

/cc @sberyozkin

[sberyozkin]

@jrepe Thanks, as I said in our earlier discussion, I don't consider it a bug since @PermitAll is not used to mark public endpoints, the authentication should still succeed. The problem is that you are saying it is not enforced for basic auth - but in your reproducer you don't have basic authentication enabled

[jrepe]

@sberyozkin Ah alright then, if it's expected for @permitAll in the context of bearer tokens, than that's alright, and I'll take that into account. Feel free to close this then.

[sberyozkin]

@jrepe It is not specific to the bearer tokens, it should also fail for the basic auth case; as I said I was testing it locally and it was failing for me too (with @PermitAll and invalid Basic auth) - in your reproducer, you only have oidc enabled, basic-auth is not enabled.
So when you send something that OIDC does not recognize (it only knows about the bearer scheme) it just lets some other mechanism to handle it - and since no other mechanism is available it succeeds. I think this is where we have an inconsistency in the way @PermitAll is treated with the proactive authentication disabled, i.e:

• If a given authentication mechanism (be it basic, oidc, etc) recognizes the credential type then it will fail with @PermitAll (here @PermitAll is indeed treated as let any authenticated user access this method)
• If none of the enabled authentication mechanisms recognizes it then it will be treated as if it is a totally public method

@stuartwdouglas I think we should be failing a request if the credential type is not recognized in case of @PermitAll, what do you think ?

@jrepe Can you please try @Authenticated instead of @PermitAll and see what happens to the basic auth test in your reproducer ?

[sberyozkin]

I think this issue may be related, #17591

[sberyozkin]

@jrepe I'm pretty sure now that what you observe is related to #17591, so I will investigate when I can get a chance; but also I'd expect that with the enabled basic authentication you'd get 401 with @PermitAll

[sberyozkin]

@jrepe That said, the current behavior in your reproducer makes sense; OIDC itself can't fail the request if it does not recognize the credential type, and since no basic is enabled it is effectively an anonymous request which succeeds against @PermitAll.
So @PermitAll does trigger the authentication even if the proactive auth is disabled but also accepts the anonymous requests - which is the inconsistency that we'd need to address.

Try @Authenticated please

[stuartwdouglas]

@PermitAll is used to mark public endpoints, with proactive auth disabled and @PermitAll no auth attempt should be made (assuming there are not other security rules defined in the config).

[jrepe]

@stuartwdouglas @sberyozkin Amazing, thanks for the quick fix :)