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

[sberyozkin]

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

[pedroigor]

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

[sberyozkin]

@pedroigor I thought I left a comment but looks like I lost it :-). Yes 2) would be good, but 1) is still needed otherwise it would not be possible to configure a web-app on the tenant-specific basis.

[pedroigor]

True. I was thinking more about supporting both web-app and service from a same app. Does it really make sense ? I mean, it clearly shows you are pushing too much to your application whereas you should, by design, have distinct applications for both back and front end ?

[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]

OK, for the sake of flexibility.

But we should probably recommend users to have better separation and don't mix these two types in a same app.

[sberyozkin]

Hi @pedroigor But it is what Google or any other hybrid-like web app is :-) - there is a dozen of options to get something out of it, with the command line tools, Java APIs, or via the direct human interaction. But agreed, we should suggest that it is not something the users should do just to make things cool :-).