Support keystore configuration for mutual TLS in oidc and oidc-client

[famod]

Description

#18012 added trust store support and we discussed key store support for client auth/mutual TLS.

This issue shall prevent that enhancement from falling through the cracks.

/cc @sberyozkin

Implementation ideas

No response

[quarkus-bot]

/cc @pedroigor, @sberyozkin

[sberyozkin]

@famod This issue is a duplicate of #4447 - which was created a long time ago - and no one has seen a requirement to talk to Keycloak using the MTLS connection. Please close one of these issues as a duplicate, perhaps we could keep this one as it is the more recent one, thanks

[famod]

@sberyozkin thanks for pointing that out! I closed the other issue as you suggested.

[sberyozkin]

@famod, by the way, if you need a way to avoid sending a client secret over the wire then you can use the client JWT authentication - is is all supported:
https://quarkus.io/guides/security-openid-connect-web-authentication#oidc-provider-client-authentication
I'm not sure what is the case for client MTLS authentication given that the JWT authentication is totally secure and does not leak the secrets on the wire. As far as the actual communication with KC is concerned, no sensitive data is flowing on the wire - the public keys are retrieved, and tokens are returned and rarely introspected

[argenstijn]

I surely would like to see support for this.

I'm not sure what is the case for client MTLS authentication given that the JWT authentication is totally secure and does not leak the secrets on the wire
Here you assume you have control over the server you call. But many don't and it is a requirement to use MTLS.
In my case it;s just how the third party server is implemented. Changing the third part server is out of our reach.

So please support this :)

[sberyozkin]

@argenstijn, sorry for a delay - I've noticed your comment only today.

Here you assume you have control over the server you call. But many don't and it is a requirement to use MTLS.

Makes sense