auth0_client datasource breaks terraform dependency graph after migrating to v1.0 of auth0 provider

[a-meynard]

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

Context & Problem

Whe migrating from auth0 provider v0.x to v1.0 I applied the migration guide and had to do the following step: Reading Client Secret. Forcing me to implement a datasource on a resource created by the same Terraform stack (stack = root module to me) because later in the stack, I configure other resource with the client_secret (notably a secret passed to the application later).

The problem is that whenever I change something on the auth0_client resource (could simply be the description of the auth0_client), then terraform also need to update resources that depends on the auth0_client datasource. I do think this is because using resource and datasource pointing to the same API resource break terraform ability to create its resource dependency graph.

see reproduction for code example of the above description.

Potential workaround / fix

While digging documentation I found the auth0_client_credentials resource. Could it be the solution to implement a proper resource dependency in terraform ? resources that use client_secret won't depends on a datasource but on the resource instead.

I'm wondering if the client_credentials resource create additional credentials or if it could return the main credentials for the auth0_client resource ? Maybe having an auth0_client_credentials datasource to get client_secret of an existing auth0_client could be a solution.

Other informations

I have found this community post: https://community.auth0.com/t/auth0-terraform-provider-1-0-0-beta-2-missing-client-secret/119194 but nothing more.

I also think this is what was described in this issue: #897. However the author did not reply so I understand it was closed. My goal here is to:

• understand why client_secret was removed (would be happy to have any issue linked to this one)
• find a workaround / fix to avoid the datasource
• If possible update the MIGRATION_GUIDE.md with the fix

Expectation

Changes on auth0_client resource not impacting credentials (client_id and client_secret) should not impact resource that depends on client_secret output of the auth0_client datasource

Reproduction

Code

resource "auth0_client" "this" {
  ...
}

data "auth0_client" "dashboard" {
  client_id = auth0_client.this.client_id
}

resource "aws_secretsmanager_secret_version" "this" {
  secret_id     = "mysecret"
  secret_string = jsonencode(
    client_id     = data.auth0_client.this.client_id
    client_secret = data.auth0_client.this.client_secret
  )
}

Problem with this code

When I change something on the auth0_client, even if not related with client_secret / client_id at all, terraform will need to re-read the auth0_client datasource making the secret_version obsolete and making terraform wanting to recreate it (because changing secret_string forces new resource). This is an example with AWS SecretsManager but it work with any resource as the problem here is that Terraform graph will cascade the datasource re-read.

Auth0 Terraform Provider version

1.3.0

###Terraform version

1.8.5

[a-meynard]

I have found those two PR:

• DXCDT-450: Remove client deprecated fields #725
• DXCDT-518: Stop requiring read:client_keys permission for reading the auth0_client_credentials resource #795

The first one actually remove the client_secret from auth0_client resource and point a second change (removal of token_endpoint_auth_method) into this part of the migration_guide, making me think that using auth0_client_credentials is the correct fix.

However, the second one makes it explicit (to me) that I won't be able to retrieve client_secret from auth0_client_credentials resource. This makes me think that I do not understand the usecase for this resource. Should we generate client_secret ourself ? Shouldn't this be handled by the auth0 provider ? If not, could we add some example of how to generate a proper client_secret in the documentation ?

[carlosjgp]

Same here
Using this pattern
https://github.com/auth0/terraform-provider-auth0/blob/e88bc9d6c55d95531e03c1dedd642f8b2a853350/MIGRATION_GUIDE.md#reading-client-secret

causes an infinite diff and there are always changes on the plan and generated "update" events on the AWS secret... which, no my case, could cause K8s PODs to restart in a bunch of scenarios I can think of