A persistent difference occurs in Terraform when the Auth0 Management API retains a legacy Single Sign-On (SSO) attribute. Resolve this configuration drift by using a lifecycle block to ignore changes or by explicitly defining the attribute in the configuration file. When using the Auth0 Terraform Provider, a persistent difference occurs when running a Terraform plan on existing Single Page Applications (SPAs) or older auth0_client resources. The plan continuously attempts to update the sso attribute from true to null and displays the following output.

~ resource "auth0_client" "spa" {
    name = "<application_name>"
  - sso  = true -> null
}

Even after running a Terraform apply command, the difference persists on subsequent plans.

• Auth0
• Auth0 Terraform Provider
  
• auth0_client resources

This issue occurs because the application historically had the sso = true flag set. Although this is a legacy attribute, the Auth0 Management API retains and returns true in the backend state during a read operation. Because the Terraform configuration block does not explicitly define the sso attribute, Terraform attempts to clear the attribute by setting it to null. The backend state continuously overrides this action, recreating the difference on every run.

How are the persistent Terraform differences for the SSO attribute resolved on Auth0 client resources?

A lifecycle block ignores changes to the backend state.

The safest approach instructs Terraform to ignore the backend state of this specific attribute using a lifecycle block, which prevents unintended side effects if Auth0 migrates or alters the client in the future. Implement the ignore_changes lifecycle block by adding the following configuration to the Terraform file.

resource "auth0_client" "spa" {
  name     = "<application_name>"
  app_type = "spa"
  # ... other configurations ...

  lifecycle {
    ignore_changes = [
      sso
    ]
  }
}

An explicit attribute definition resolves the configuration drift.

Alternatively, hardcode the legacy value into the .tf file to match the backend state, which satisfies Terraform and stops the difference immediately. Explicitly define the sso attribute by adding it to the resource block as shown in the following example.

resource "auth0_client" "spa" {
  name     = "<application_name>"
  app_type = "spa"
  sso      = true
  # ... other configurations ...
}

NOTE: Hardcoding this legacy attribute is not recommended for long-term maintainability, as it causes conflicts if the application type changes in the future. The ignore_changes method remains the preferred approach.