Auth0 Community Ask Me Anything with Auth0 Terraform Provider

Absolutely! Thankfully, getting started with the Auth0 Terraform Provider is significantly easier than in the past. With our recent Auth0 Terraform v1 release and updates to our Auth0 CLI, we have significantly reduced the initial setup time.

In the past, setting up the Auth0 Terraform Provider, especially for mature tenants, was an arduous process, to say the least. Depending on how mature your tenant is, it might have taken days or weeks to manually copy all your Auth0 resources over.

We’re happy to report that now you can get started with Terraform in minutes, not days! To start, developers should follow our straightforward Quickstart guide to understand the general concepts. If you are already using Auth0, you only need to run the new auth0 terraform generate command in the Auth0 CLI to generate all the .tf files needed for Terraform. More details on the terraform generate feature can be found here

We are very committed to leveling up our guidance and documentation, so if you run into any issues, please don’t hesitate to send any feedback to GitHub.


Terraform providers do not directly handle secret management themselves. Instead, secret management in Terraform typically involves integrating with external tools or services designed for managing secrets.

Here are some best practices for managing secrets in the context of Terraform:

  • Avoid Plain Text Secrets: It’s crucial not to store secrets in plain text within your Terraform code. Remember that anyone with access to your version control system can potentially access these secrets.
  • Secure Terraform State: Ensure the security of your Terraform state by storing it in a backend that supports encryption, such as S3, Google Cloud Storage (GCS), or Azure Blob Storage. Additionally, tightly control who has access to your Terraform backend to prevent unauthorized access.
  • Use Environment Variables: When providing client credentials or API tokens for authentication with the Auth0 Provider, consider using environment variables. This approach keeps sensitive information separate from your code and allows for easier management.
  • Leverage Dedicated Secret Stores: For enhanced security, store your secrets in a dedicated secret store. These are specialized databases designed to securely store sensitive data and tightly control access. Some popular options to consider include HashiCorp Vault, AWS Secrets Manager, AWS Parameter Store, and Google Cloud Secret Manager.

By following these best practices, you can ensure that your secrets remain secure and your Terraform configurations are both effective and safe.


Terraform is designed to play well with pretty much every CI/CD workflow and integrating the Auth0 Terraform Provider into a CI/CD pipeline can streamline the process of managing your Auth0 resources, making it more automated, consistent, and error-free. A few ways the Auth0 Terraform Provider fits into a CI/CD pipeline are with:

  • Version Control: Your Terraform configuration files, which include your Auth0 resources, can be stored in a version control system like Git. This allows you to track changes, collaborate among team members, and rollback if needed.
  • Automated Testing: Before applying any changes, you can run terraform plan as a step in your CI pipeline to review the changes that will be made. This can be automated to run on every commit or pull request to ensure that only intended changes are applied.
  • Configuration Consistency: By using Terraform to manage your Auth0 resources, you ensure that your configurations are consistent across different environments (dev, staging, production). This is crucial for maintaining a reliable and secure system.
  • Automated Deployments: The terraform apply command can be run automatically in the CD portion of your pipeline to apply the changes to your Auth0 configuration. This can be triggered manually after review or automatically after a successful test phase.
  • Monitoring: You can set up monitoring and alerts for your Auth0 resources directly from your CI/CD pipeline, ensuring real-time feedback on the state of your infrastructure.
  • **Code Reviews:**Terraform configuration changes can go through the same peer review process as any other code changes, ensuring quality and compliance.

Especially for large tenants, we feel that utilizing Terraform and the Auth0 provider is a critical step to managing your tenants effectively at scale.


To answer the second part your question first, Organizations are definitely the way to go now, and we have quite a bit of comprehensive documentation on how they work and how to get the most out of them.

As for managing multiple tenants in Terraform, the ideal approach depends on your specific use case and organizational requirements.

Here are some best practices for managing multiple Auth0 tenants in Terraform:

  • Directory Structure: Organize your Terraform code into a directory structure that separates environments.
  • Variable Files: Create separate variable files for each environment (e.g., dev.tfvars, staging.tfvars, production.tfvars). These files should contain environment-specific variable values.
  • Terraform Modules for Reusability: Consider creating Terraform modules that encapsulate common Auth0 configurations (e.g., creating custom database connections, defining roles, or setting up identity providers). These modules can be reused across different tenants, reducing duplication of code.
  • Remote State Management: Store Terraform state files for each environment separately. Utilize remote state backends (e.g., S3, GCS, Azure Blob Storage) with different state file paths or prefixes for each environment to prevent state file conflicts.
  • Use Terragrunt (Optional): Consider using Terragrunt, an additional tool that simplifies managing multiple environments with Terraform. Terragrunt can help manage remote state, variable files, and common configurations in a more structured way.

We have typically stayed away from this type of guidance in our documentation largely because the Auth0 Terraform Provider is designed to work within the standard confines of Terraform, and there are several different ways you can use Terraform, depending on your project. That being said, as we see questions like this come up from the community, we’re encouraged to put forth more focused guidance to fill in some of Hashicorp’s documentation gaps. If there are any specific documentation and guidance requests, feel free to submit them to GitHub, and we’ll see about getting them added!


In general, we recommend that any resources created outside Terraform be imported into Terraform’s management purview with the Terraform import command. Each Auth0 resource has specific documentation on importing resources (see: email provider import docs). This will allow you to incur less of the conflicts that you describe. If you believe you are experiencing a bug with the provider, please open an issue in GitHub, and the team will dig in!


During its inception, the Auth0 Terraform Provider was maintained largely by Alex Kalyvitis and the community. However, as time went on we recognized the need for rapid innovation and development in this space and brought the development of the Auth0 Terraform Provider in-house. This is why you now see the project under the Auth0 organization in GitHub. Auth0 Terraform Provider along with the Auth0 CLI and Auth0 Deploy CLI are now maintained full time by the Developer Experience - Customer Developer Tooling team here at Okta.

We happy to report that we’ve been quite focused on Terraform over the past quarter and encourage everyone to checkout our new v1 release!


Great question! The recent fork of Terraform by OpenTF has certainly garnered attention in the developer community. At Okta, we are committed to providing a seamless experience for our users, regardless of the tools they choose to use.

Currently, we foresee no immediate issues for developers wishing to transition to OpenTF. Our Auth0 Terraform Provider is designed to be compatible with the Terraform ecosystem, and we aim to maintain that compatibility as the landscape evolves.
However, while OpenTF aims to be fully compatible with existing Terraform providers, unforeseen challenges or issues could arise as the project and Terraform mature. We will be closely monitoring developments related to OpenTF, and should we see a significant fork between the two (no pun intended), we’ll address them accordingly.

We are also open to community contributions and feedback to improve compatibility and address any concerns arising from this fork. If you encounter any issues or have further questions, please don’t hesitate to contact us on our Community site or GitHub repository.


A post was split to a new topic: Problem with Auth0 and MongoDB

As per Auth0 docs we don’t have an option to manage tenant members via Terraform, do we’ve any plans in near future to handle them with Terraform resources?
and also at present do we have any other ways to manage them apart from Auth0 management API & Auth0 dashboard portal?

At present, our team is overseeing four distinct tenants through the Auth0 Terraform provider. We have encountered a straightforward requirement: configuring universal login/branding for these tenants. In our pursuit of enhancing the user experience, we seek to validate these branding changes locally before applying them to the respective tenants.

Could you provide guidance on the process for running the universal login/branding Terraform code locally and subsequently validating the proposed changes?

A post was split to a new topic: Question about Auth0 Terraform possibilities

A post was split to a new topic: Question about Auth0 Terraform Provider

Hi @vaishnavbawanaka,

Welcome to the Auth0 Community!

I would suggest creating a staging or dev tenant for testing changes before pushing them to your production instances.

Hi @rp185255,

We have an open feature request for this. Please follow here: Management API support for managing tenant members

hi @dan.woda :

I’m currently facing 403s when attempting to modify/create auth0_client resources. I get the following message:

Error: 403 Forbidden: The account is not allowed to perform this operation, please contact our support team.

My tenant’s subscription is an Enterprise Agreement type.

Do you have an idea of why this may be happening? my M2M application has all scopes enabled.

1 Like

I’m facing the exact same issue. I was able to create auth0_resource_server, but not able to create an auth0_client resource.

Hey there @elopez and @luis.ordaz !

As you are both on enterprise tier in order to solve it most effectively and as advised per the error message, can I ask you to open a support ticket in our Auth0 Support Center? This way we can take a closer look at it with our developer support engineers. Thank you!

thanks @konrad.sopala !

I did that and I was able to get an answer! It’s due to the setting of an attribute: require_pushed_authorization_requests.

Even if it’s false, the inclusion of that attribute within the resource blocks causes this behavior. I believe that should be considered a bug (I filed a request at the provider repo). This attribute is OPTIONAL, hence, given this last fact, I would consider having it set to false and non-existent being the same.

@elopez : remove this attribute from the resource block you’re trying to modify (even if it’s set to false).

1 Like

Yes, I’m testing removing all the null and default values and also worked for me. Thanks for replying.

1 Like

No problem! Glad you solved it and shared with community!