Sending clientId/clientSecret as form params during a code flow does not work with Okta

[sberyozkin]

Description
Aaron Anderson linked to this Vertx OAuth2 issue which is about the adapter duplicating the OIDC client authentication in the Authorization header by sending the same clientId and clientSecret info as the form parameters which some OIDC providers such as Okta don't like.

Implementation ideas
Introduce a configuration property to let the users specify how to post the clientId/clientSecret (Authorization header - default, form parameters - only if some providers require it) once https://github.com/vert-x3/vertx-auth/issues/319 is fixed

[pedroigor]

The configuration property makes sense. I'm wondering now if that idea we discussed about having "profiles" for the different implementations make sense. Something like a quarkus.oidc.provider=keycloak|okta|auth0 to dictate the defaults for each one.

[sberyozkin]

Hi Pedro @pedroigor, Paulo @pmlopes has just merged a fix into Vertx Oauth2.
Yeah, some kind of a grouping concept may be done as part of #4448, but that would be up to the user how to qualify the configurations, the adapter is generic so it would be simpler if if we can try to keep the configuration generic. That said, I'm not sure with the current fix the new property is needed :-), so I'll likely close the issue once Quarkus is updated to Vertx-OAuth2 3.8.5

[pmlopes]

Hi @sberyozkin the fix is already on 4.0.0rc5 but not backported to 3.8 branch yet (the branches are quite apart so it's not a trivial backport if no new 3.8 release is planned soon).

[sberyozkin]

@pmlopes thanks for also backporting a fix to 3.8.5-SNAPSHOT :-) I've asked at the users list to confirm it helps (I'm sure it helps :-) )