Introduce a config builder for OIDC Client Registration

[michalvavrik]

This is but part of phase 2 agreed here #39185 (comment).
We agreed to start with the OIDC Client Registration because its API is experimental, therefore we can make changes on it and it's better to make breaking changes sooner than later.
This PR:

• introduces builder for OidcClientRegistrationConfig config group that users will use when they register new OIDC Client
• migrates io.quarkus.oidc.client.registration.OidcClientRegistrations from former config group class to config group interface
• OidcCommonConfig now implements @ConfigMapping config group interface, which means we can use the interface without converting it to the class when not necessary (and we are not breaking anything); this needs to be done so that OIDC Common utils can accept both former class and new config

When this PR is merged, it will be easier to follow with similar changes for the OIDC and OIDC Client extensions because they share OidcCommonConfig.

[github-actions]

🙈 The PR is closed and the preview is expired.

[sberyozkin]

Hi @michalvavrik Looks good, thanks, how will a more complex sequence look like, where some metadata are supplied as well ?

[michalvavrik]

Hi @michalvavrik Looks good, thanks, how will a more complex sequence look like, where some metadata are supplied as well ?

It's flat structure because metadata has so little properties that I thought it was overkill to create extra .metadata().clientName("name").redirect.....

You could find some examples in tests that I added, but basically this is how it works:

var config = OidcClientRegistrationConfig.builder()
                .extraProperty("metadata-extra-prop-key-1", "metadata-extra-prop-val-1")
                // or
                .extraProps(Map.of("one", "one", "two", "two"))
                .clientName("metadata-client-name")
                .redirectUri("metadata-redirect-uri")
                .postLogoutUri("metadata-post-logout-uri")
                // and now continue with wehatever you like
                .id("client-id-1")
                .build();

[sberyozkin]

@michalvavrik See, there will be a lot of such sub-interfaces for OidcTenantConfig, so now we have an opportunity to work out now how to make it as easy as possible for the users. I'm not too keen on having everything flat, IMHO, metadata should have its own build support to be distinctive from the rest of the key properties like registration url, and what would be nice is to be able to do either metadata().clientName()... as part of the main builder sequence, or for the main builder sequence to do .metadata(metadata) where metadata was built independently.

I'd also like to suggest to offer shortcuts to let users minimize a number of .builder().
For example, OidcClientRegistrationConfig.registrationUri(someUrl) returns a Builder...

[michalvavrik]

@michalvavrik See, there will be a lot of such sub-interfaces for OidcTenantConfig, so now we have an opportunity to work out now how to make it as easy as possible for the users. I'm not too keen on having everything flat, IMHO, metadata should have its own build support to be distinctive from the rest of the key properties like registration url, and what would be nice is to be able to do either metadata().clientName()... as part of the main builder sequence, or for the main builder sequence to do .metadata(metadata) where metadata was built independently.

I'd also like to suggest to offer shortcuts to let users minimize a number of .builder(). For example, OidcClientRegistrationConfig.registrationUri(someUrl) returns a Builder...

Alright, I'll look into it.

[michalvavrik]

Hello @sberyozkin , I believe I have addressed your feedback.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit fea29ab.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit fea29ab.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.