auth0_connection scope not applied

[HugoKNL]

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of this provider and the issue still persists.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

When applying the auth0_connection resource, given you specify scopes as a set of strings (as mentioned in the docs, and not passing validation otherwise), the parsing goes wrong and the scopes end up as an array of strings in the connection instead of one string with the scopes being separated by spaces.

Expectation

I expect to be able to declare the auth0_connection options block's scopes as a set of strings (like the docs prescribe) and then have them being parsed as a whitespace separated string before being applied.

The underlying request should have this syntax:

"scope": "foo bar"

Reproduction

1. Given you specify the auth0_connection options block's scopes parameter like this:

scopes         = ["foo", "bar"]

2. When you perform a terraform apply
3. The scopes are applied as an array of strings
4. The management dashboard UI shows the strings comma separated and shows an error (cause it needs to be a string)
5. A GET request on the connection through the management api shows:

"scope": [
      "foo",
      "bar"
    ],

6. When you update the connection through the management dashboard UI to "foo bar", it'll add the scopes param like this to the request:

"scope": "foo bar"

7. A GET request on the connection through the management api shows:

"scope": "email openid profile"

Auth0 Terraform Provider version

1.19.1

Terraform version

1.11.2

[duedares-rvj]

For different type of connection, the scope object is populated differently. Could you share which type of connection are you trying to create here?

[HugoKNL]

For different type of connection, the scope object is populated differently. Could you share which type of connection are you trying to create here?

It is a "social connection" with the oauth2 strategy I am trying to create.

[bchrobot]

We are experiencing this as well, also with the oauth2 strategy and provider version 1.35.0.

I see that the implementation of the json.Unmarshaler interface for ConnectionOptionsOAuth2 in github.com/auth0/go-auth0 v1.31.0 (v1.31.0 being the version used by the Terraform provider for this) does handle either a string or an array of strings:

// UnmarshalJSON implements the json.Unmarshaler interface for ConnectionOptionsOAuth2.
// It is required to handle differences in the scope field, which can
// be an array of strings or a single string.

and it looks like the ConnectionOptionsOAuth2 struct stores scopes as a single string.

But the MarshalJSON implementation always converts to an array of strings:

scopes := strings.Fields(*c.Scope)

This is confirmed by running TF_LOG=debug terraform apply with scopes as a space-separated string.

I see that the Auth0 API returns scopes as an array:

GET /api/v2/connections/con_REDACTED HTTP/1.1

{"id":"con_REDACTED","options":{"scope":["openid","offline_access","profile"]}: timestamp=2025-11-17T08:19:10.707-0500

The Terraform plan shows the a single space-separated string:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # auth0_connection.this will be updated in-place
  ~ resource "auth0_connection" "this" {
        id                   = "con_REDACTED"
        name                 = "my-custom-oauth2"
        # (5 unchanged attributes hidden)

      ~ options {
            name                                   = null
          ~ scopes                                 = [
              - "offline_access",
              - "openid",
              - "profile",
              + "openid offline_access profile",
            ]
            # (88 unchanged attributes hidden)
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

And the resulting PATCH operation sends an array of strings:

PATCH /api/v2/connections/con_REDACTED HTTP/1.1

{"options":{"scope":["openid","offline_access","profile"]}}

It seems like the options are:

1. Make the API more tolerant such that it can handle a space-separated string OR an array of strings
2. Update the logic around json.Marshaler to send space-separated vs array of strings as appropriate/do not lump all OAuth2-based social connections together if they in fact behave differently

[duedares-rvj]

Hi @HugoKNL and @bchrobot 👋

Thank you both for your insights and contributions to this discussion.
We’ve identified the scope handling issue and appreciate the proposed resolutions. As you mentioned, one approach would be to make the API more tolerant to both space-separated strings and arrays, or alternatively, refining the JSON marshaling logic to handle different connection strategies appropriately.

I want to assure you that our team is actively working on this.
Currently, the API team is undergoing a major rework to standardize the options schema. This rework will differentiate connection-specific structures, ensuring that each connection type (like OAuth2, Apple, or Facebook) has its own tailored schema. Once this standardization is complete, we’ll also update the Terraform provider to reflect these changes, ensuring that we no longer need to lump different connection types together.

This means that, in the coming quarters, we’ll have a more robust and flexible schema that will effectively resolve these scope handling issues. We’re closely monitoring the progress and will keep you updated as things evolve.

We appreciate your patience and collaboration, and we’ll make sure to keep you informed as we move forward.

Thank you!