Auth0 Community Ask Me Anything with Auth0 Terraform Provider

Auth0 by Okta Community Ask Me Anything with Auth0 Terraform Provider

The Auth0 Community is excited to invite you to our next interactive online Ask Me Anything (AMA) session on Thursday, September 28, 2023, featuring the Auth0 Terraform Provider Product Team.

Did you know that the Auth0 Terraform Provider offers a streamlined way to manage Auth0 configurations using Infrastructure as code, allowing for easy version control, automation, and integration into existing DevOps pipelines? No matter where you are in your journey with Auth0, we’ve got you covered! Kevin Lillybridge, Group Product Manager at Auth0 will answer your burning questions, from how to get started with the Auth0 Terraform Provider to best practices, common use cases, and how to integrate Auth0 configurations into existing DevOps workflows.

How will the AMA session work? From today, September 7 to Wednesday, September 27, 2023, you can ask your questions by replying to this discussion thread using the ‘Reply’ Button. Then, mark your calendars for Thursday, September 28, between 7 a.m. and 9 a.m. PST, when our product experts from the Auth0 Terraform Provider team will provide you with comprehensive written answers. As a bonus, your participation will earn you points and a special badge.

What you’ll gain from participating?

  • How to get started with the Auth0 Terraform Provider
  • How to seamlessly integrate Auth0 management into CI/CD pipelines
  • Common pitfalls to avoid when using the Auth0 Terraform Provider
  • Information on advanced use cases for the Auth0 Terraform Provider
  • How to manage multiple environments with the Auth0 Terraform Provider
  • Best practices for managing Auth0 resources with Terraform

Ask Questions here by hitting the reply button! Be sure to submit your questions from Thursday, September 7 to Wednesday, September 27, 2023.

Featured Expert

Kevin Lillybridge is a Group Product Manager in the Developer Experience Organization. He works with Auth0’s Developer Tooling and SDKs team, helping developers supercharge building with Auth0.

This is part of a monthly interactive online AMA series that invites the Auth0 by Okta Community to engage with various Okta subject matter experts.


With the recent fork of Terraform by OpenTF it sounds like all providers will continue to function as expected - Does Okta have any thoughts on this or foresee any potential issue for developers who wish to transition to OpenTF in the spirit of open source?


What is the current maintenance model of Auth0 Terraform Provider? Is Auth0 managing the repo for the tool ourselves or is someone outside of the company still doing this with us?


Can you walk us through the initial setup process for the Auth0 Terraform Provider?


How does the Auth0 Terraform Provider handle secret management?


How does the Auth0 Terraform Provider fit into a CI/CD pipeline?

:video_camera: Want to join our next Community Interactive Q&A with our experts? This time we’re gonna talk about Auth0 Terraform Provider


Creating a resource in the Auth0 UI, like email provider, causes errors when creating the resource with terraform afterwards. I wasn’t able to delete the resource completely after creating it in the UI, so I ran into a lot of terraform creation errors. It could not destroy nor replace. What are your thoughts on this?


Hey there everyone!

Most of you probably don’t remember but it was @alexkappa, one of our community members who initially set the foundation for this tool!

If you wish to read more about the tool beginnings here is our blog article on that front:

We would also love to encourage @alexkappa to join our AMA and share his thoughts about the tool! Thank you Alex for all the core ground work you did at the beginning for this tool!


Hey there everyone!

While we’re waiting for our AMA: Auth0 Terraform Provider to happen this Thursday between 7 a.m. and 9 a.m. PST, we’ve got another Terraform related update for all of you!

Auth0 Terraform Provider Version 1 GA Released!

Our engineering team is thrilled to announce the highly anticipated GA release of our Auth0 Terraform Provider v1! With the v1 release, managing your Auth0 resources using Terraform has never been easier. From provisioning clients, configuring connections, or setting up actions, the Auth0 Terraform Provider v1 empowers developers to streamline and automate their Auth0 infrastructure faster than ever before. Key Highlights:

  • Auto-generating Terraform Config: By leveraging the Auth0 CLI, you can automatically generate the necessary Terraform code to provision and manage resources in Auth0.
  • Data Sources for Resources: Easily fetch and reference data from existing Auth0 resources using data sources.
  • Resource Relationships: Define and manage relationships between Auth0 resources effortlessly.
  • Zero Downtime Client Secret Rotation: Seamlessly rotate client secrets with minimal disruption to applications and users.
  • Bug Fixes and Stability Enhancements: Auth0 Terraform Provider v1 emphasizes our dedication to delivering an enhanced, reliable tool.

Quickstart | Documentation | Migration Guide | Discussions


Howdy Konrad!

I have two questions that I am bursting to ask, the first: whats the Auth0 ‘ideal’ approach to managing multiple tenants in Terraform?

I’ve seen some answers on issues in Github which suggested using a workspace per tenant, but using Terraform workspaces to manage environments can to be contraversial. I’d love to see how you’d put it into action.

My second question which is loosely Terraform related - are subtenants still a thing, or are organisations the way to go now?

Consider the below use case:

An international organisation managing country-specific applications, these applications may have alternative auth flows depending on the country they are depoloyed into, and are managed by a team within that country.

One way of managing this would be to set up multiple tenants specific to each country, but this feels like it would get messy quickly as the tenants would all be floating in a pool together - hence, subtenants, but then again Organisations? I don’t know enough about Organisations to know!


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?