Expose potential extension points on authorization code flow-related provider clients

[FelixMundial]

Description

Our self-hosted authorization server is based largely upon basic authorization code flow backed by OIDC, but slightly modified the "code -> token" process as several non-standard parameters are required, which are primarily headers and bodies for signature submission intended for customized client authentication based on methods other than the standard ones like base/post/jwt or secret_key_jwt, for the exchange of id/access/refresh tokens.
This whole process is not at all universal in terms of keycloak or other well-known providers, but the ability of extention/decoration of the authorization code flow would be of benefit.
Thank you for your time :))

Implementation ideas

In io.quarkus.oidc.runtime.OidcProviderClient#getHttpResponse(String, MultiMap), it seems that headers and bodies are not somewhat customizable, I wonder if it's feasible to enable passage of customized header/body values to the http client, through configuration properties.
Or is it possible to enable decoration of the whole io.quarkus.oidc.runtime.CodeAuthenticationMechanism, through conditional injection of user-defined OidcProviderClients.

[quarkus-bot]

/cc @pedroigor

[sberyozkin]

@FelixMundial
Do you need to have an option to pass the extra HTTP headers and extra form parameters with the code grant request ?
We can just add 2 more Map configuration properties, one accepting the extra headers (we have such an option for quarkus-oidc-client too), and another one - the extra form parameters.

Will that work for you ?

[FelixMundial]

@FelixMundial Do you need to have an option to pass the extra HTTP headers and extra form parameters with the code grant request ? We can just add 2 more Map configuration properties, one accepting the extra headers (we have such an option for quarkus-oidc-client too), and another one - the extra form parameters.

Will that work for you ?

Thank you for your instant reply!
These two configuration properties would help a lot for such "weird" situations as ours:))
Still, I am not quite sure whether this "customizability" should be included in the core quarkus-oidc/quarkus-oidc-client, or should instead be made possible by means of other extensions closely related to them (in the form of different artifacts), because I am afraid these configuration properties would have barely any use to other quarkus-oidc users tackling general authorization code grant processes, thus making the quarkus-oidc polluted or abused by "my proposes":(
And given these worries, I wonder how you would regard the "user-defined OidcProviders injection" approach, which is inspired by Spring Security filter chains, as opposed to what most of the discussions were covering, the "configuration properties" approach.

[sberyozkin]

@FelixMundial Np, adding the configuration properties is the simplest approach and trying to make it more complex without real need for it is not needed IMHO - doing the extra grant handlers will increase the margin of a user error and complicate the already complex quarkus-oidc code even more.
For example, users can already supply the additional parameters which will be sent to the authorization endpoint as query parameters at the start of the code flow - it makes sense to match it with having the same feature when completing the code flow.
And as I said, quarkus-oidc-client already has an option to send custom HTTP headers during its grant requests, so makes sense to have the same option at the quarkus-oidc level.
It will be optional so won't affect other users who do not need it

[FelixMundial]

@sberyozkin Then this enhancement is currently the best option for it, thank you very much for your explanation and help🥳🥳

[sberyozkin]

@FelixMundial Np, I'll let you know when PR is available, once I get to it...

[sberyozkin]

@FelixMundial FYI, #27482 will close this issue once approved/merged. It can be of general interest - but please give it a try and re-open the issue if some extra customizations may be necessary

[FelixMundial]

@FelixMundial FYI, #27482 will close this issue once approved/merged. It can be of general interest - but please give it a try and re-open the issue if some extra customizations may be necessary

OK, sure :)