OIDC Client repeatedly adds client-id when no secret is specified

[darraghc345]

Describe the bug

When configuring an OIDC client, if only the client-id is used for the request, then the client id will be concatenated to every request until an new instance of the client is created.

Issue comes from how the formBody is created.

OidcClientImpl.getJsonResponse(...) line 111

else if (!OidcCommonUtils.isClientSecretPostAuthRequired(oidcConfig.credentials)) {
    body.add(OidcConstants.CLIENT_ID, oidcConfig.clientId.get());
}

We are using Quarkus version 2.7.5.Final.

Expected behavior

client-id should only be added to the request once.

As a workaround you can add a dummy client-secret to the oidc client configutration.

quarkus.oidc-client.credentials.client-secret.value=xxx
quarkus.oidc-client.credentials.client-secret.method=post

Actual behavior

client-id is concatenated to every request.

public class OidcClass {

  @Inject
  @NamedOidcClient("test")
  OidcClient oidcClient;

  public Uni<String>getToken() {
    return oidcClient.getTokens().map(tokens -> BEARER_KEYWORD + tokens.getAccessToken())
  }
}

Calling getToken() multiple times results in the following form bodies for the http requests:

------------------- 1st request -----------------------

grant_type=password
username=xxx
password=xxx
client_id=public

-------------------- 2nd request -------------------

grant_type=password
username=xxx
password=xxx
client_id=public
client_id=public

------------------- 3rd request ---------------

grant_type=password
username=xxx
password=xxx
client_id=public
client_id=public
client_id=public

How to Reproduce?

Configure an OidcClient with the following settings

quarkus.oidc-client.auth-server-url=xxx
quarkus.oidc-client.discovery-enabled=false
quarkus.oidc-client.token-path=/protocol/openid-connect/token
quarkus.oidc-client.client-id=public
quarkus.oidc-client.grant.type=password
quarkus.oidc-client.grant-options.password.username=xxx
quarkus.oidc-client.grant-options.password.password=xxx

[quarkus-bot]

/cc @pedroigor, @sberyozkin

[sberyozkin]

Sure, the situation where a password grant is used with a public client has never been considered, I'm assuming it is a test case scenario as opposed to the production case. But we'll need to fix it anyway