"invalid_client" "Please provide valid client credentials using HTTP Basic Authentication."

[nxverma]

we are facing issue while running TF code . Our creds are correct as working in Postman and other

Error: Post "https://api.us-central1.gcp.commercetools.com/<project_key>/tax-categories": oauth2: "invalid_client" "Please provide valid client credentials using HTTP Basic Authentication."

[demeyerthom]

Hi @nxverma

Hmm, that is a strange error. I am assuming the provider itself is also configured correctly? Do you maybe have more information for me? When did this start happening? What are you trying to execute?

Thanks!

[totalbot123]

We are observing similar issues in our environments. Example error:

Post "***/***/product-types": oauth2: "invalid_client" "Please provide valid client credentials using HTTP Basic Authentication."
│ 
│   with module.commercetools.module.productType.module.product_type["product"].commercetools_product_type.this,
│   on .terraform/modules/commercetools.productType.product_type/main.tf line 1, in resource "commercetools_product_type" "this":
│    1: resource "commercetools_product_type" "this" ***

We provide:

COMMERCETOOLS_CLIENT_ID
COMMERCETOOLS_CLIENT_SECRET
COMMERCETOOLS_PROJECT_KEY
COMMERCETOOLS_SCOPES
COMMERCETOOLS_API_URL
COMMERCETOOLS_TOKEN_URL

Scopes given: manage_project:our-project view_audit_log:our-project manage_api_clients:our-project view_api_clients:our-project

Plan worked as expected but we are observing this on apply.

Provider version: 1.14.1
Environment: GH (RHEL container)

[motizukilucas]

Hi any updates on this topic?

I ran into the same issue with following terraform code:

terraform {
    required_providers {
        commercetools = {
            source  = "labd/commercetools"
        }
    }
}

provider "commercetools" {
    client_id     = var.client_id
    client_secret = var.client_secret
    project_key   = var.project_key
    scopes        = "manage_project,manage_products,manage_orders,manage_customers,manage_categories,manage_types,manage_zones" # https://docs.commercetools.com/merchant-center-customizations/concepts/oauth-scopes-and-user-permissions#oauth-scopes
    api_url       = "https://api.europe-west1.gcp.commercetools.com/" # https://docs.commercetools.com/api/general-concepts#hosts
    token_url     = "https://auth.europe-west1.gcp.commercetools.com/" # https://docs.commercetools.com/api/authorization
}

resource "commercetools_store" "my-client-a-store" {
    key = "my-client-A-store"
    name = {
    en-US = "My client A"
    }
    countries             = ["US", "UK"]
    languages             = ["en-US", "en-UK"]
}

[motizukilucas]

Managed to get a working setup with following terraform, by appending authentication in token_url as shown here: https://docs.commercetools.com/getting-started/make-first-api-call#auth-url-and-parameters

terraform {
    required_providers {
        commercetools = {
            source  = "labd/commercetools"
        }
    }
}

provider "commercetools" {
    client_id     = var.client_id
    client_secret = var.client_secret
    project_key   = var.project_key
    scopes = "manage_project:${var.project_key}"
    api_url       = "https://api.europe-west1.gcp.commercetools.com/" # https://docs.commercetools.com/api/general-concepts#hosts
    token_url     = "https://${var.client_id}:${var.client_secret}@auth.europe-west1.gcp.commercetools.com/" # https://docs.commercetools.com/api/authorization
}

resource "commercetools_store" "my-client-a-store" {
    key = "my-client-A-store"
    name = {
    en-US = "My client A"
    }
    countries             = ["US", "UK"]
    languages             = ["en-US", "en-GB"]
}

[marquesVF]

We're encountering the same issue.

After some investigation with GODEBUG=http2debug=2 TF_LOG=DEBUG, it seems the problem lies in how the provider handles authentication. Currently, it's sending the client_id and client_secret in the body of the POST request using application/x-www-form-urlencoded.

However, Commercetools expects these credentials to be passed using HTTP Basic Authentication instead.

To reproduce the issue with curl:

This fails (credentials in the body):

curl -X POST \
  https://auth.europe-west1.gcp.commercetools.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET"

This works (credentials via Basic Auth):

curl -X POST \
  https://auth.europe-west1.gcp.commercetools.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
  -d "grant_type=client_credentials"

It would be great if the provider supported sending credentials via Basic Auth.

[demeyerthom]

Hi all,

The provider can actually do both. We use the oauth2 package from golang.org/x/oauth2, which has an AuthStyle option that determines whether to send credentials via headers or in the body. By default (the one that is configured) it will try both and cache the successful one for future use.

By default it should hit the headers first, and try params afterwards.

I can definitely add an env variable to force it to one or the other, but I am more curious why in the above cases it would not be able to use the headers method at all. This seems more of an issue with the API endpoint (and the requests being sent) than the provider per se.

@marquesVF do you have more information on if it failing to send the authentication via header before trying the body?