Improve OIDC multi-tenancy and "web-app" configuration support

Description Right now the tenant-specifc web-app application-type will be ignored unless a default configuration is provided. For example, configuring only:

quarkus.oidc.tenant-1.auth-server-url=${keycloak.url}/realms/quarkus
quarkus.oidc.tenant-1.application-type=web-app
quarkus.oidc.tenant-1.client-id=quarkus-app
quarkus.oidc.tenant-1.credentials.secret=secret

will log a warning that quarkus.oidc.tenant-1.application-type property is not supported. The reason for that is that the application-type property is a build time property and as such it is not available at the moment the tenant configuration is resolved. And because a service type is a default value, only the Bearer mechanism would be registered at the deployment time.

So for the code-flow to work with the multi-tenancy, one needs to have a default configuration even if it is not used:

# Default config just to make the Tenant specific configuration work in the code flow mode
quarkus.oidc.auth-server-url=${keycloak.url}/realms/quarkus
quarkus.oidc.application-type=web-app

# Tenant 1 configuration
quarkus.oidc.tenant-1.auth-server-url=${keycloak.url}/realms/quarkus

# Tenant 2 configuration
quarkus.oidc.tenant-2.auth-server-url=${keycloak.url}/realms/quarkus

#etc

Implementation ideas

• Make applicatiion-type a runtime property
• Instead of registering either Bearer or CodeFlow authentication mechanism at the deployment time, register a composite OidcAutenticationMechanism which will have both of those authentication mechanisms available and delegate to the right one depending on whatever the resolved context’s application type is.

This way we will also be able to support an application which can act both as a service and a web-app application.

CC @pedroigor @stuartwdouglas

[sberyozkin]

@pedroigor This is what multi-tenancy gives us 😃 and in itself the issue of having a web-app cleanly supported on a per-tenant basis (which is what this issue is primarily about) would require the application-type becoming a runtime property which in turn would require the composite mechanism. I think it is reasonable in that we will have have the human users authenticating directly against the web-app which would also be able to accept the bearer tokens from the java script running applications. I believe a good number of applications can do it, interact with the human users and also accept the HTTP calls from all sort of HTTP clients. I’ll do a PR and we will all discuss more 😃

[pedroigor]

@sberyozkin I would go for #2 (composite mechanism) so that people can support both bearer and code on a per-tenant basis.