Unable to use OAuth2 authentication

[aprodhomme-dkt]

Hi,

Before using your http-connector we need first to be able to authenticate to an API provider with oauth2. Unfortunately the API Publishers didn't implement a standard way to retrieve an access token. Instead they developed their own api with the following form (see https://api.didomi.io/docs/#/sessions/post_sessions):

{
  "type": "api-key",
  "key": "my_client_id",
  "secret": "my_secret"
}

Our proposal is to bring additional configuration to configure the form field. For example we would have the following configuration to implement the oauth2 form described above:

{
  "name": "http-sink-test",
  "config": {
    "connector.class": "io.aiven.kafka.connect.http.HttpSinkConnector",
    "topics.regex": "domain_a.*",
    "http.url": "http://httpmockserver:1080",
    "http.authorization.type": "oauth2",
    "http.headers.content.type":  "application/json",
    "oauth2.access.token.url":  "http://httpmockserver:1080/oauth2",
    "oauth2.client.authorization.mode": "URL",
    "oauth2.grant_type.key": "type",
    "oauth2.grant_type": " api-key",
    "oauth2.client.id":   "my_client_id",
    "oauth2.client.id.key":  "key",
    "oauth2.client.secret":  "my_secret",
    "oauth2.client.secret.key":  "secret",
    "key.converter": "org.apache.kafka.connect.storage.StringConverter",
    "value.converter": "org.apache.kafka.connect.json.JsonConverter"
  }
}

We already have made a fork to implement this issue on our side as we need to move forward on our production schedule. For that 2 PRs were pushed:

• Refactor of HttpSender implementations with Factory Pattern (1/2) #171: a refactor in order to properly test each configuration and ensure we are still able to use oauth2 with default values.
• Add oauth2 configuration (2/2) #172: additional oauth2 configuration

Thank you

[aprodhomme-dkt]

Hi @jeqo , as you mentioned a few months ago, we reworked our code and pushed 2 PR to help reviewer to understand the modifications.

[jeqo]

@aprodhomme-dkt thanks for this proposal. I agree the current sender logic requires a refactor, and the proposed factory pattern fits very well IMO.

I do also agree that the customizing the field names is a good improvement. We are doing similar with the access token field by defining a custom property name oauth2.response.token.property.

Let's just be careful we are not breaking existing functionality and behavior. We can discuss this on the PRs specifically.

Thanks again!