Make quarkus-oidc properties more generic

[sberyozkin]

Description
Stian:

Perhaps obvious, but as it is renamed to be more generic so should the config options. One example is to set the URL of the IdP it should be setting the URL of the discovery endpoint (with or without .well-known/openid-configuration, as that can be added if missing). So for configuring Keycloak it should be something like:

discoveryUrl=https://auth.company.com/auth/realms/myrealm
Instead of auth-server-url and realm which Keycloak adapters use.

[sberyozkin]

@stianst @pedroigor @stuartwdouglas, @pmlopes I've looked at the code.
Only 3 properties are used so I'd like to trim off everything else and Pedro can start adding whatever is needed back once he completes his Vertx adapter review. The properties which are used are:
resource, auth-server-url and realm.
We can collapse them into per Stian's suggestions into
resource -> client-id (though I recall Paulo said something about Azure or some provider where resource is more suitable ?)
and auth-server-url and realm -> discovery-uri (I'm using -uri instead of -url because Vertx uses -uri too)

I'll create a PR either tomorrow or Mon morning sharp and we'll finalize the details
Thanks

[pmlopes]

Azure uses resource for something else that resembles keycloack realm it's a guid that identifies the application.

[pmlopes]

To clarify, vertx uses this config:

https://github.com/vert-x3/vertx-auth/blob/master/vertx-auth-oauth2/src/main/java/io/vertx/ext/auth/oauth2/OAuth2ClientOptions.java

The important ones are: site (bad name I guess that represents the base url to the idp) clientId, clientSecret. The all endpoints are the path variables. Which can be either a path that is appended to site, or if it's a url it's used autonomously. And then there's a bunch of config for keys when they are loaded offline and tweaks needed for different providers.

[sberyozkin]

Hi @pmlopes, All,
I've been thinking more and I'm not sure any longer we should collapse auth-base-url and realm into discovery-url, because some providers may not have discovery-url as a base url for all other endpoints. I think we just need to make realm optional in case some of the servers don't have that concept, and introduce the introspection-path from what Paulo linked to, and keep growing the config from there. We can rename auth-base-url to say idp-base-url I guess...

[sberyozkin]

I'm thinking of keeping auth-base-url as is, as the users won't have to change it, it is generic enough, I'll add a comment it is a base IDP URL. The other thing is that if we want this module to do the opaque token verification issued by non-OIDC but OAuth2 only servers (to do what quarkus-elytron-security-oauth2 does) then auth-base-url may fit well...

[sberyozkin]

But I guess I have to drop the realm as implied by Stian because keeping it does not help users avoiding having to add "/realms" to the base URL anyway :-)

[stianst]

Without a discovery endpoint multiple URLs would have to be configured by the user, not just a auth_base_url. A base URL would only work if you know the type of the IdP and what layout it uses for URLs.

So I would go for discovery-url, but also allow specifying the URLs within directly if an IdP doesn't support the discovery endpoint. That is a fairly long list though (authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, registration_endpoint). There is also a lot more config that can be retrieved from the discovery endpoint that can be used to correctly configure things.

[sberyozkin]

Hi Stian, sure, as per the PR discussion we will support the discovery seamlessly, either by having the adapter to recognize the auth-base-url fits the standard discovery URL pattern or by sticking to the path based approach and adding a relative discovery path property or may be indeed introducing a dedicated discovery-url property as per your original proposal as it may offer a cleaner separation between a manual approach (auth-base-url + relative paths) vs the auto discovery one (discovery-url)... As I said I'm going to open a dedicated issue asap with CC to you and Pedro