Regression issue: OIDC is failing to start even when authentication is disabled

[Sgitario]

Describe the bug

Having a Quarkus application with resteasy and OIDC, and disabling the authentication for all endpoints using:

quarkus.oidc.tenant-enabled=false

# HTTP Security Configuration
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=permit

When we run the app, it fails with:

java -jar target/quarkus-app/quarkus-run.jar 
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2021-03-25 10:39:38,648 ERROR [io.qua.run.Application] (main) Failed to start application (with profile prod): java.util.MissingFormatArgumentException: Format specifier '%s'
	at java.base/java.util.Formatter.format(Formatter.java:2672)
	at java.base/java.util.Formatter.format(Formatter.java:2609)
	at java.base/java.lang.String.format(String.java:2897)
	at io.quarkus.oidc.common.runtime.OidcCommonUtils.verifyCommonConfiguration(OidcCommonUtils.java:35)
	at io.quarkus.oidc.runtime.OidcRecorder.createTenantContext(OidcRecorder.java:117)
	at io.quarkus.oidc.runtime.OidcRecorder.createStaticTenantContext(OidcRecorder.java:100)
	at io.quarkus.oidc.runtime.OidcRecorder.setup(OidcRecorder.java:49)
	at io.quarkus.deployment.steps.OidcBuildStep$setup-635434700.deploy_0(OidcBuildStep$setup-635434700.zig:100)
	at io.quarkus.deployment.steps.OidcBuildStep$setup-635434700.deploy(OidcBuildStep$setup-635434700.zig:40)
	at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:521)
	at io.quarkus.runtime.Application.start(Application.java:90)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:100)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
	at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:48)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:25)

Note that I'm aware that we can disable OIDC using the property quarkus.oidc.enabled, but this property is managed at build time. Therefore, the only way to enable/disable OIDC authentication at runtime is via the properties described above.

The same was working fine in 1.12.2.Final, but not in 1.13.0.Final.

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. mvn io.quarkus:quarkus-maven-plugin:1.13.0.Final:create -DprojectGroupId=org.acme -DprojectArtifactId=getting-started -DplatformGroupId=io.quarkus -DplatformVersion=1.13.0.Final -DclassName="org.acme.quickstart.GreetingResource" -Dpath="/hello"
2. Add OIDC: mvn quarkus:add-extension -Dextensions=oidc
3. Add the above properties to the application.properties:

quarkus.oidc.tenant-enabled=false

# HTTP Security Configuration
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=permit

4. Run the project: mvn clean verify

[quarkus-bot]

/cc @pedroigor, @sberyozkin

[gsmet]

Two things here:

• looks like you would have an exception anyway so it's probably worth to check if this use case is supposed to be working
• I'm pretty sure you need to use %1$s if you want to use the same parameter several times

[sberyozkin]

The code branch where Uni is expected to be returned if the tenant is disabled is missing a return - hmm... looks like the quarkus-oidc/deployment test which checks that it works is not good... By the way, Jose @Sgitario, some regressions were caught early, before the release - can the tests which caught this one also be enabled to run against the snapshots ?
Going to fix shortly

[sberyozkin]

OK, the reason the code flow dev mode test works is because it checks that TenantConfigResolver can back-up with a dynamic tenant if the default one is disabled

[sberyozkin]

And it is also getting an expected 401 when the protected resource is accessed - but there the client_id is present but wrong - while in this case it is missing.
So there are 2 issues here:

• Disabled tenant Uni is not used - once it is fixed there will be no exception
• Wrong message format when the exception is reported

[sberyozkin]

@Sgitario, by the way, I started working on addressing #15933.
So tenant-enabled=false would become less useful when dealing with the default config - can be more interesting in a multi-tenancy case though

[Sgitario]

@Sgitario, by the way, I started working on addressing #15933.
So tenant-enabled=false would become less useful when dealing with the default config - can be more interesting in a multi-tenancy case though

Outstanding work @sberyozkin ! Also I see you have already covered this scenario in upstream.
About not using tenant-enabled for this use case after you finished #15933 , it sounds much better +1

[sberyozkin]

Hi @Sgitario You are very kind :-), I'd like to hide myself for that super no return code :-)

[sberyozkin]

Closing manually as I mistyped Fixes in the PR