Terraform Provider for the Auth0 platform.

Overview

Auth0 Terraform Provider

GoDoc License Tests Release


Terraform Provider for the Auth0 platform.

Note: This Provider was previously maintained under alexkappa/terraform-provider-auth0.


Table of Contents


Installation

Terraform 0.13+

Terraform 0.13 and higher uses the Terraform Registry to download and install providers. To install this provider, copy and paste this code into your Terraform configuration. Then, run terraform init.

terraform {
  required_providers {
    auth0 = {
      source  = "auth0/auth0"
      version = "0.17.1"
    }
  }
}

provider "auth0" {}
$ terraform init

Terraform 0.12.x

For older versions of Terraform, binaries are available at the releases page. Download one that corresponds to your operating system / architecture, and move it to the ~/.terraform.d/plugins/ directory. Finally, run terraform init.

provider "auth0" {}
$ terraform init

[table of contents]

Documentation

See the Auth0 Provider Documentation for all the available resources.

Usage

You can find examples on usage under the example folder.

[table of contents]

Contributing

See CONTRIBUTING.md.

[table of contents]

What is Auth0?

Auth0 helps you to:

  • Add authentication with multiple authentication sources, either social like Google, Facebook, Microsoft Account, LinkedIn, GitHub, Twitter, Box, Salesforce, amont others, or enterprise identity systems like Windows Azure AD, Google Apps, Active Directory, ADFS or any SAML Identity Provider.
  • Add authentication through more traditional username/password databases.
  • Add support for linking different user accounts with the same user.
  • Support for generating signed Json Web Tokens to call your APIs and flow the user identity securely.
  • Analytics of how, when and where users are logging in.
  • Pull data from other sources and add it to the user profile, through JavaScript rules.

[table of contents]

Create a free Auth0 Account

  1. Go to Auth0 and click "Try Auth0 for Free".
  2. Use Google, GitHub or Microsoft Account to login.

[table of contents]

Issue Reporting

If you have found a bug or if you have a feature request, please report them at this repository issues section. Please do not report security vulnerabilities on the public GitHub issue tracker. The Responsible Disclosure Program details the procedure for disclosing security issues.

[table of contents]

Author

Auth0

[table of contents]

License

This project is licensed under the MPL-2.0 license. See the LICENSE file for more info.

[table of contents]

Comments
  • `legacy_custom_claims` flag on `auth0_tenant` resource

    `legacy_custom_claims` flag on `auth0_tenant` resource

    Checklist

    Describe the problem you'd like to have solved

    The ability to toggle the usage of namespaced custom claims in JWT tokens was recently added to the Auth0 Dashboard in Tenant Settings (Advanced). Screenshot 2022-08-19 at 20 33 00

    Will this be added to terraform-provider-auth0 and to the go-auth0 as a prerequisite? It seems like the update (PATCH) is made via the manage.auth0.com/api/migrations endpoint versus manage.auth0.com/api/tenants/settings so the Management API may need to be changed first? Thanks!

    Describe the ideal solution

    resource "auth0_tenant" "my_tenant" {
      friendly_name = "Legacy Custom Claims flag added"
    
      flags {
        legacy_custom_claims = false
      }
    }
    

    Alternatives and current workarounds

    No response

    Additional context

    No response

    feature resource/auth0_tenant 
    opened by nialdaly 11
  • Passwordless Email Connection Unsupported

    Passwordless Email Connection Unsupported

    Description

    The terraform-provider-auth0 implementation does not support Passwordless Email connection resources; the definitions for the email block are missing for connections with a strategy of "email".

    A related, but substantively different, issue is filed here: https://github.com/auth0/terraform-provider-auth0/issues/31

    Affected Resource(s)

    • auth0_connection

    Expected Behavior

    Given the below connection from the Auth0 Management API api/v2/connections endpoint (as derived from the defaults for a new tenant), the terraform-provider-auth0 should be able to successfully import this connection by ID as well as successfully plan and apply a resource that defines all aspects of this connection:

    {
        "id": "con_ABCDEFGHIJKLMNOP",
        "options": {
            "name": "email",
            "totp": {
                "length": 6,
                "time_step": 180
            },
            "email": {
                "body": "<html>Removed for brevity.</html>",
                "from": "{{ application.name }} <[email protected]>",
                "syntax": "liquid",
                "subject": "Welcome to {{ application.name }}"
            },
            "authParams": "",
            "disable_signup": false,
            "brute_force_protection": true
        },
        "strategy": "email",
        "name": "email",
        "is_domain_connection": false,
        "realms": [
            "email"
        ],
        "enabled_clients": [ ]
    }
    

    Reproduction

    Assuming a Passwordless Email connection is enabled in the tenant with ID con_ABCDEFGHIJKLMNOP, attempting to import the Passwordless Email connection results in an error:

    ❯ terraform import auth0_connection.email con_ABCDEFGHIJKLMNOP
    
    auth0_connection.email: Importing from ID "con_ABCDEFGHIJKLMNOP"...
    auth0_connection.email: Import prepared!
      Prepared auth0_connection for import
    auth0_connection.email: Refreshing state... [id=con_ABCDEFGHIJKLMNOP]
    ╷
    │ Error: decoding response payload failed: json: cannot unmarshal string into Go struct field ConnectionOptionsEmail.authParams of type map[string]string
    │ 
    │ 
    ╵
    

    Similarly, creating an auth0_connection resource like the below results in validation and plan failures for the email block:

      resource "auth0_connection" "email" {
        enabled_clients      = [ ]
        is_domain_connection = false
        name                 = "email"
        realms               = [
          "email",
        ]
        strategy             = "email"
        options {
            totp {
              length                = 6
              time_step             = 180
            }
      
            email {
              body                  = "<html>Removed for brevity.</html>"
              from                  = "{{ application.name }} <[email protected]>"
              syntax                = "liquid"
              subject               = "Welcome to {{ application.name }}"
            }
      
            disable_signup          = false
            brute_force_protection  = true
        }
      }
    
    ❯ terraform plan                        
    │ Error: Unsupported block type
    │ 
    │   on email.tf line 22, in resource "auth0_connection" "email":
    │   22:       email {
    │ 
    │ Blocks of type "email" are not expected here.
    ╵
    

    Environment

    The following version is defined for the terraform-provider-auth0:

    terraform {
        required_providers {
          auth0 = {
            source = "auth0/auth0"
            version = "~> 0.30.3"
          }
        }
      }
      
    

    No other modules, plugins, or libraries are in use.

    Community Note

    • Please vote on this issue by adding a :+1: reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue or have submitted a pull request, please leave a comment
    bug resource/auth0_connection 
    opened by cs-jackb 10
  • Dependency didn't resolved between trigger binding and action when we want to delete an action.

    Dependency didn't resolved between trigger binding and action when we want to delete an action.

    From terraform-provider-auth0 created by hknerts: alexkappa/terraform-provider-auth0#515

    Description

    Dependency didn't resolved between trigger binding and action when we want to delete an action.

    First we deleted trigger binding resource then we delete action. We had to do it this way for now.

    Terraform Version

    v0.12.20

    Terraform <TERRAFORM_VERSION>
    + provider.auth0 <TERRAFORM_PROVIDER_VERSION>
    

    TERRAFORM_VERSION = 0.12.20 TERRAFORM_PROVIDER_VERSION = 0.26.1

    Affected Resource(s)

    • auth0_action
    • auth0_trigger_binding

    Terraform Configuration Files

    
    https://gist.github.com/hknerts/39b1d03a2d244cd811bf08df9f8580ba
    

    Expected Behavior

    resolve dependency between action and trigger binding

    Actual Behavior

    didnt resolved dependency between action and trigger binding

    Steps to Reproduce

    1. terraform apply

    Debug Output

    image

    Panic Output

    Important Factoids

    References

    • #0000

    Community Note

    • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
    • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
    • If you are interested in working on this issue or have submitted a pull request, please leave a comment
    bug resource/auth0_action resource/auth0_trigger_binding 
    opened by sergiught 10
  • seg fault on terraform plan for `auth0_guardian` resource

    seg fault on terraform plan for `auth0_guardian` resource

    Checklist

    • [X] I have looked into the README and have not found a suitable solution or answer.
    • [X] I have looked into the documentation and have not found a suitable solution or answer.
    • [X] I have searched the issues and have not found a suitable solution or answer.
    • [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
    • [X] I agree to the terms within the Auth0 Code of Conduct.

    Description

    We're currently experiencing a seg fault error attempting to plan a auth0_guardian with version v0.30.2.

    I also commented out our guardian resource, and ran into the same error when trying to plan a auth0_role resource.

    Details of stack trace:

    ╷
    │ Error: Plugin did not respond
    │ 
    │ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ReadResource call. The plugin logs may contain more details.
    ╵
    ╷
    │ Error: Request cancelled
    │ 
    │   with module.auth0.auth0_email.my_email_provider[0],
    │   on ../modules/auth0/main.tf line 9, in resource "auth0_email" "my_email_provider":
    │    9: resource "auth0_email" "my_email_provider" {
    │ 
    │ The plugin.(*GRPCProvider).UpgradeResourceState request was cancelled.
    ╵
    ╷
    │ Error: Plugin did not respond
    │ 
    │   with module.auth0.auth0_role.admin,
    │   on ../modules/auth0/roles.tf line 1, in resource "auth0_role" "admin":
    │    1: resource "auth0_role" "admin" {
    │ 
    │ The plugin encountered an error, and failed to respond to the plugin.(*GRPCProvider).ValidateResourceConfig call. The plugin logs may contain more details.
    ╵
    
    Stack trace from the terraform-provider-auth0_v0.30.2 plugin:
    
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x2 addr=0x0 pc=0x10115d834]
    
    goroutine 46 [running]:
    github.com/auth0/terraform-provider-auth0/auth0.flattenAuth0Options(0x14000403e00)
            github.com/auth0/terraform-provider-auth0/auth0/resource_auth0_guardian.go:370 +0x54
    github.com/auth0/terraform-provider-auth0/auth0.readGuardian({0x10144f590?, 0x140003be390?}, 0x101c8d3c8?, {0x10138dec0?, 0x14000403e00})
            github.com/auth0/terraform-provider-auth0/auth0/resource_auth0_guardian.go:316 +0x32c
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0x140003b3ea0, {0x10144f590, 0x140003be390}, 0xd?, {0x10138dec0, 0x14000403e00})
            github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:724 +0xec
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).RefreshWithoutUpgrade(0x140003b3ea0, {0x10144f590, 0x140003be390}, 0x14000422820, {0x10138dec0, 0x14000403e00})
            github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:1015 +0x46c
    github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadResource(0x140002952a8, {0x10144f4e8?, 0x14000430240?}, 0x140004302c0)
            github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:613 +0x40c
    github.com/hashicorp/terraform-plugin-go/tfprotov5/tf5server.(*server).ReadResource(0x1400040e000, {0x10144f590?, 0x140000f0e10?}, 0x140006420c0)
            github.com/hashicorp/[email protected]/tfprotov5/tf5server/server.go:746 +0x3b8
    github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadResource_Handler({0x101415080?, 0x1400040e000}, {0x10144f590, 0x140000f0e10}, 0x14000642060, 0x0)
            github.com/hashicorp/[email protected]/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:349 +0x174
    google.golang.org/grpc.(*Server).processUnaryRPC(0x140002ac8c0, {0x101452028, 0x140001024e0}, 0x14000185200, 0x140003dce70, 0x10190c950, 0x0)
            google.golang.org/[email protected]/server.go:1282 +0xb3c
    google.golang.org/grpc.(*Server).handleStream(0x140002ac8c0, {0x101452028, 0x140001024e0}, 0x14000185200, 0x0)
            google.golang.org/[email protected]/server.go:1619 +0x840
    google.golang.org/grpc.(*Server).serveStreams.func1.2()
            google.golang.org/[email protected]/server.go:921 +0x88
    created by google.golang.org/grpc.(*Server).serveStreams.func1
            google.golang.org/[email protected]/server.go:919 +0x298
    
    Error: The terraform-provider-auth0_v0.30.2 plugin crashed!
    
    This is always indicative of a bug within the plugin. It would be immensely
    helpful if you could report the crash with the plugin's maintainers so that it
    can be fixed. The output above should help diagnose the issue.
    

    Expectation

    Even if this resource is misconfigured, I would expect this provider not to seg fault.

    However, I have not changed this resource between plans and it is now reliably failing.

    Reproduction

    1. Given i install the provider at version v0.30.2
    2. When I try to create an auth0_guardian or auth0_role resource
    3. I get a seg fault

    Auth0 Terraform Provider version

    auth0_guardian

    Terraform version

    v1.2.7

    bug 
    opened by acookin 9
  • app_domain

    app_domain

    Describe the problem

    https://github.com/auth0/terraform-provider-auth0/pull/202#issuecomment-1168863713 suggests that app_domain is not set in state, therefore removing it will not affect things.

    This has not been my experience. app_domain for a connection does exist in my connections that are created on 0.30.2 and 0.31.0 - my state is in a GCP backend so I cannot easily edit it. I attempted to use terrform state pull to retreive it, manually remove app_domain form my connecitons and terraform state push <statefile> to push it back up but the internal verifications are stopping the push due to the serial being the same.

    How can I safely progress - do i need to manually manipulate my state?

    What was the expected behavior?

    Expected that the deprecated value being removed would not affect my existing state.

    Reproduction

    1. Create a connection in 0.30.2 for strategy facebook, or google-oauth2, or auth0
    2. Update to 0.32.0 terraform init -upgrade
    3. terraform plan, or terraform apply now error.
    bug resource/auth0_connection 
    opened by arcticShadow 9
  • Add addons.samlp.issuer field to client resource

    Add addons.samlp.issuer field to client resource

    🔧 Changes

    This PR adds support for the issuer field within the samlp client addon. The issuer defaults to urn:your_tenant.auth0.com if not set explicitly. It can be set to something else including the proto part, for example; https://mydomain.com.

    📚 References

    🔬 Testing

    I've added the option to the existing testAccClientConfig test.

    📝 Checklist

    • [x] All new/changed/fixed functionality is covered by tests (or N/A)
    • [x] I have added documentation for all new/changed functionality (or N/A)
    opened by xens 8
  • Application must not have Token Endpoint Authentication Method

    Application must not have Token Endpoint Authentication Method

    Describe the problem

    We encountered this issue when applying a plan.

    1. There did not appear to be any issue when the plan was generated

    2. Running apply for this plan failed with:

      Error: 400 Bad Request: Application must not have Token Endpoint Authentication Method set to "none" when client_credentials grant type is enabled

    3. Searching for all of these on google yielded no relevant results

      • https://www.google.com/search?client=firefox-b-d&q=%22Application+must+not+have+Token+Endpoint+Authentication+Method%22
    4. Searching auth0's documentation did not yield any actionable hits

      • https://auth0.com/docs/search?q=Application%20must%20not%20have%20Token%20Endpoint%20Authentication%20Method&page=1
    5. Searching auth0's community forum did not yield any actionable hits

      • https://community.auth0.com/t/i-cannot-setup-password-in-auth0-dashboard/66297

    What was the expected behavior?

    Either succeed, or there should be a page somewhere explaining how to resolve this (this ticket could suffice, but actual documentation would be better)

    Reproduction

    1. have an auth0 tenant with an app_type of spa
    2. have a terraform json with an auth0_client containing a map of app_types including the spa

    If so, provide steps:

    1. run terraform plan and see a vaguely reasonable plan
    2. run terraform apply and get an error

    Environment

    Please provide the following:

    • terraform0.12.26
    • Version of terraform-provider-auth0 used: terraform-provider-auth0_v0.14.0_x4
    invalid question 
    opened by bgolding355 8
  • Redesign connection-client association to be controlled via its own resource (instead of only by the connection)

    Redesign connection-client association to be controlled via its own resource (instead of only by the connection)

    Checklist

    Describe the problem you'd like to have solved

    We have a fairly static set of Auth0 connections from which we draw bodies of users. Adding new bodies of users is fairly rare. Ergo, we have a single Terraform root module that controls each Auth0 connection.

    We dynamically generate Auth0 applications/clients. Adding new templated Auth0 application/clients is fairly regular. Ergo, we have a single Terraform root module that can be run in multiple tf workspaces with different variables to generate a (theoretically) infinitely scalable number of application/clients.

    Each application/client should be associated with a dynamic combination of connections, dependent on the variables passed to the application/client. For example, I might spin up an application/client that should only be reachable by two of my customers, and I might spin up a near-identical application/client that should only be reachable by one of my customers and our internal team.

    Currently, there is no way for our lovely application/client terraform module to automatically associate the brand spanking new application with an existing connection. One has to spin up the application and either manually set the 'toggle' slider from the application/client's 'connections' tab in the dashboard, OR one has to edit the connections terraform root module and add the client_id to the enabled_clients argument for the connection.

    Why is this bad?

    1. Manual action sucks, so that rules out the dashboard like right away.
    2. Having to tweak two terraform modules in a specific order is a pretty irritating barrier to automation. It means two git pushes.
    3. Deleting an application/client before it was removed from the 'connections' terraform module means the 'connections' terraform module would immediately become invalid (because you better believe I'm not hardcoding client_ids, I'm using an auth0_client datasource) and would need edited and the offending client removed (which is also hard because THE APPLICATION IS ALREADY GONE and the data source that refers to it is now invalid. We're talking some direct terraform state work if the application destruction wasn't done in a perfectly precise order).
    4. Codified methods of determining what application/clients are reachable by what users is particularly difficult. I have to go through each connection terraform remote module and figure out what each set of users has access to, then filter that by the application I care about... instead of simply asking the application.
    5. All companies on the planet have 'legacy' junk that was set up manually by some yahoo, right? We're no different. We have some 'connections' which are not terraformed. I can't edit these connections via terraform for bureaucracy reasons, which means I have no codifiable recourse to attaching new application/clients to them!

    In short, managing the association between application/clients and connections must be done in multiple places in a specific order... and it shouldn't be that way! This really hamstrings the usefulness of Terraform in general, where a single terraform apply can bring up all the resources necessary for a specific modular subset of your overall infrastructure.

    Describe the ideal solution

    Taking a page from the AWS provider's book, let's look at how they handle aws_security_groups, which are a resource that be thought of akin to a grouping of firewall rules. "If the connection comes from the 10.0.0.0/8 CIDR, allow it, but if it comes from 10.1.0.0/16, deny it." This is a resource - like your auth0_connection - that is often associated with several other resources (rules) - like your auth0_clients.

    https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group

    At first glance, the security group is set very similar to allowed clients in your connections resource - a list of 'ingress' and 'egress' rules. However, the AWS provider also provides the following resource:

    https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group_rule

    This resource allows you to specify an arbitrary rule and assign it to an existing security group. If you had a central security group (that controlled access to, say, a virtual machine) and created a fresh resource that should have access to the security group, you could simply create an aws_security_group_rule resource and associate it to the security group INSTEAD of having to hunt down the existing aws_security_group's terraform module and plug in a data source (that can't be guaranteed to continually exist).

    Using this method, one generates an empty security group in a single terraform module (call it module A) (much like generating an unassociated auth0_connection) that protects an asset with a 'deny' flag, and then any time someone creates a terraform module (call it module B) with resources that should be allowed to pass the security group, module B simply adds the aws_security_group_rule resource to the security group built in module A. Module B can be templated and run in many different terraform workflows to always create a rule and always plug it into the security group from A, without ever needing to edit and re-run A... and removing a rule is as simple as destroying module B.

    I would love to see an auth0_connection_client_association resource that follows this same strategy.

    Alternatives and current workarounds

    Manually doing things in the dashboard, in the cases where I cannot edit a connection via terraform (ie, data source only)

    Additional context

    Kudos to you for working on the provider in general!

    feature 
    opened by dputnamfr 7
  • Missing handling for HTTP 429 Too Many Requests Response

    Missing handling for HTTP 429 Too Many Requests Response

    Checklist

    • [X] I have looked into the README and have not found a suitable solution or answer.
    • [X] I have looked into the documentation and have not found a suitable solution or answer.
    • [X] I have searched the issues and have not found a suitable solution or answer.
    • [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
    • [X] I agree to the terms within the Auth0 Code of Conduct.

    Description

    A change in 92a913858eefb1953e5d642310f9e16df71509be acknowledges that there are rate limits for Auth0's APIs (there also are authentication rate limits). However, it is not really a proper fix, it just means that anyone using terraform may suffer from these failures instead of anyone trying to contribute to this project.

    • https://community.auth0.com/t/getting-429-errors-before-the-x-ratelimit-remaining-header-runs-out/59875/1
    • https://community.auth0.com/t/429-too-many-requests/81374

    Expectation

    1. When terraform-provider-auth0 makes a request, it should look at the rate limit response headers and store their values.
    2. If a response indicates that it's approaching a rate limit, it should slow down.
    3. If a response is a 429, trigger a full backoff. Wait until an appropriate amount of time has elapsed and retry.
    4. It should be possible to revert 92a913858eefb1953e5d642310f9e16df71509be and tests should pass, albeit more slowly.

    Reproduction

    1. Given a developer (or free) auth0 tenant

    2. Set up a management api

    3. generate terraform json which has the following keys:

        "auth0-yyy-client_id": {
        "auth0-monitoring-client_id": {
        "auth0-monitoring-client_secret": {
        "auth0-xxx_auth0_client_id": {
        "auth0-xxx_auth0_client_id": {
        "auth0-xxx_auth0_client_id": {
        "auth0-xxx_auth0_client_id": {
      "auth0_resource_server": {
      "auth0_user": {
      "auth0_tenant": {
      "auth0_client": {
      "auth0_client_grant": {
      "auth0": {
      
    4. perform a terraform apply

    Or somehow create a terraform plan that involves 6-12 tasks which should result in at least 6 requests in under 1 second which is apparently in excess of 2 requests per second with a burst of ??

    To review, you can go to the auth0 /logs endpoint and search for client_id:... for the client id from 2. Then for each event, open the url in a new tab and copy out the url and timestamp.

    I've provided a sample including a bit of data about the 429:

    Timestamp | Event -|- 2022-08-08T18:43:14.458Z | 2022-08-08T18:43:58.628Z | 2022-08-08T18:43:58.896Z | 2022-08-08T18:43:58.659Z | 2022-08-08T18:43:58.436Z | 2022-08-08T18:43:58.598Z | 2022-08-08T18:43:58.786Z | 2022-08-08T18:43:58.886Z | api_limit - Global limit has been reached

    Auth0 Terraform Provider version

    v0.14.0_x4

    Terraform version

    0.12.26

    invalid question 
    opened by jsoref 7
  • Missing argument for

    Missing argument for "Add Permissions in the Access Token" in auth0_resource_server

    Describe the problem

    The dashboard interface for API's shows an "Add Permissions in the Access Token" option under "RBAC Settings" that adds a permissions claim to the access_token. This argument seems to be missing from the auth0_resource_server docs. This makes it impossible to correctly configure the API with Terraform.

    What was the expected behavior?

    An extra argument for the "Add Permissions in the Access Token" in auth0_resource_server that can be set to true

    Reproduction

    Docs for resource

    resource "auth0_resource_server" "default" {
      name        = "Example Resource Server (Managed by Terraform)"
      identifier  = "https://api.example.com"
    
      # Enable RBAC
      enforce_policies = true
    
      # Option for adding permission claim to access_token?
    }
    

    The resource above does enable RBAC.

    Environment

    • Version of terraform-provider-auth0 used: v0..33.0
    documentation question resource/auth0_resource_server 
    opened by jeroenmarchand 7
  • Error: string is required for `options` field in `auth0_connection`

    Error: string is required for `options` field in `auth0_connection`

    Describe the problem

     Error: string is required
    with auth0_connection.user_database
    on main.tf line 75, in resource "auth0_connection" "user_database": 
    

    The line mentioned is options {

    This happens when upgrading from 0.31.0 to 0.32.0. Seems like it could be related to https://github.com/auth0/terraform-provider-auth0/issues/251

    What was the expected behavior?

    Reproduction

    resource "auth0_client" "management_client" {
      name = "Auth0 Management Client"
    
      app_type                   = "non_interactive"
      token_endpoint_auth_method = "client_secret_post"
    
      grant_types     = ["client_credentials"]
      oidc_conformant = true
      jwt_configuration {
        lifetime_in_seconds = 3600 // 1 hour
        alg                 = "RS256"
      }
    }
    
    resource "auth0_client_grant" "management_client_grant" {
      client_id = auth0_client.management_client.id
      audience  = "https://${local.auth0_domain}/api/v2/"
      scope = [
        "create:users",
        "create:user_tickets"
      ]
    }
    
    resource "auth0_connection" "user_database" {
      name            = "Username-Password-Authentication"
      strategy        = "auth0"
      enabled_clients = [auth0_client.management_client.id]
    
      options {
        brute_force_protection = true
        disable_signup         = true
        password_policy        = "excellent"
        password_history {
          enable = true
          size   = 24
        }
        password_no_personal_info {
          enable = true
        }
        password_dictionary {
          enable = true
        }
      }
    }
    

    Environment

    This happens when upgrading this provider from 0.31.0 to 0.32.0. Terraform version 1.2.5. Plan is on terraform cloud.

    bug 
    opened by tizz98 7
  • `auth0_branding_theme` requires all args

    `auth0_branding_theme` requires all args

    Checklist

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

    Description

    auth0_branding_theme schema requires all fields (which made me click around manually in the end - I do NOT want to provide all the arguments - auth0 defaults work well for me except a couple of exceptions) meanwhile auth0_branding has all fields optional (which is nice and easy to use)

    Expectation

    auth0_branding_theme fields are optional, just like auth0_branding

    Reproduction

    go to https://registry.terraform.io/providers/auth0/auth0/latest/docs/resources/branding_theme

    Auth0 Terraform Provider version

    0.40.0

    Terraform version

    1.3.5

    feature 
    opened by TiltUp-Rad 2
  • Support for custom database connections breaks when enabling script context

    Support for custom database connections breaks when enabling script context

    Checklist

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

    Description

    Once you've enable custom database context for a connection, the provider leaves enable_script_context as false since it is not supported, causing:

    │ Error: 400 Bad Request: once enabled, options.enable_script_context can not be disabled
    

    Expectation

    Either the API needs to not set any value (leave as is) when not provided, or support for enable_script_context will need to be added to the connection options.

    Reproduction

    1. Given an auth0 connection with a custom database created with Terraform.
    2. When Context object in database scripts is enabled for the connection.
    3. Then any further attempts to run Terraform against the connection fail with the 400 error: once enabled, options.enable_script_context can not be disabled

    Auth0 Terraform Provider version

    0.40

    Terraform version

    1.3.6

    bug 
    opened by matthosking-mydeal 0
  • auth0_client custom_login_page management

    auth0_client custom_login_page management

    Checklist

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

    Description

    Actually, in my company Terraform topology, we used on auth0_client custom_login_page capability. We want to remove it from our topology to manage it directly by Auth0 management API. When I remove this options custom_login_page and custom_login_page_on in my terraform topology, when I launch a plan, I show a login page removal. After apply my modification, when I launch a new plan, I always show my login page in terraform plan diff.

    Expectation

    After apply, I won't see login page diff in my terraform plan

    Reproduction

    1. Have a terraform topology auth0_client with custom_login_page and custom_login_page_on describe
    2. Apply this topology
    3. Remove custom_login_page and custom_login_page_on in my auth0_client topology
    4. Plan and show custom_login_page removal
    5. Apply
    6. Plan again and show custom_login_page still exists

    Auth0 Terraform Provider version

    0.40.0

    Terraform version

    1.1.3

    bug 
    opened by nlarcher-talend 0
  • cannot manage auth0 management api with terraform

    cannot manage auth0 management api with terraform

    Checklist

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

    Description

    Referring to https://github.com/auth0/terraform-provider-auth0/pull/374, it should be possible to modify the auth0 management API via terraform, however, this does not seem to work for me as expected, the following code in a terraform module fails:

    resource "auth0_resource_server" "auth0" {
    	name = "Auth0 Management API"
    	identifier = var.auth0-mgmt-api-identifier
    	token_lifetime = 86400
    	skip_consent_for_verifiable_first_party_clients = false
    }
    
    ## grant access to management api
    resource "auth0_client_grant" "mgmt_api_grant" {
      client_id = auth0_client.client-service.id
      audience  = auth0_resource_server.auth0.identifier
      scope = ["create:user_tickets",
              "create:users",
              "read:users",]
    }
    

    (var.auth0-mgmt-api-identifier contains the identifier found in the auth0 dashboard).

    With the following error message:

    Error: 400 Bad Request: The identifier https://<tenant>.eu.auth0.com/api/v2/ is not available for use, as it is reserved by Auth0.
    │ 
    │   with module.auth0_config.auth0_resource_server.auth0,
    │   on ../../modules/auth0/main.tf line 16, in resource "auth0_resource_server" "auth0":
    │   16: resource "auth0_resource_server" "auth0" {
    

    Expectation

    I should be able to modify the settings of the auth0 management API via terraform.

    Reproduction

    This is a minimal configuration that fails for me:

    resource "auth0_resource_server" "auth0" {
    	name = "Auth0 Management API"
    	identifier = var.auth0-mgmt-api-identifier
    	token_lifetime = 86400
    	skip_consent_for_verifiable_first_party_clients = false
    }
    
    ## grant access to management api
    resource "auth0_client_grant" "mgmt_api_grant" {
      client_id = auth0_client.client-service.id
      audience  = auth0_resource_server.auth0.identifier
      scope = ["create:user_tickets",
              "create:users",
              "read:users",]
    }
    

    Auth0 Terraform Provider version

    0.40

    Terraform version

    1.3.5

    question waiting for customer 
    opened by hkolvenbach 1
  • 409 Conflict: There was an error creating branding settings

    409 Conflict: There was an error creating branding settings

    Checklist

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

    Description

    Resource auth0_branding_theme is not working. When adding the resource to terraform i get an 409 even on the first try, i also don't see any Themes in the auth0 UI

    │ Error: 409 Conflict: There was an error creating branding settings: theme already exists

    If i try to import the default Theme first i get after changing the Theme

    │ Error: 400 Bad Request: Path validation error: 'Object didn't pass validation for format theme-id: default' on property themeId (The ID of the theme).

    Expectation

    Setting a custom theme or updating the default Theme should work without any error.

    Reproduction

    1. Create auth0_branding_theme
    2. Run Terraform apply

    Auth0 Terraform Provider version

    v0.40.0

    Terraform version

    v1.3.3

    feature 
    opened by Nightapes 3
  • `auth0_organization_member` resource state refresh fails when user has been removed from organization

    `auth0_organization_member` resource state refresh fails when user has been removed from organization

    Checklist

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

    Description

    If a auth0_organization_member resource exists in Terraform state, but the corresponding organization member does not exist in Auth0, state refresh fails with

    Error: 404 Not Found: User is not a member of this organization
    

    The resource has to be manually removed from state with terraform state rm to proceed.

    Expectation

    State refresh should succeed and the resource should automatically be removed from state.

    I believe it is standard behaviour for providers to handle "not found" errors in this way. See for example https://github.com/hashicorp/terraform-provider-aws/blob/ef1fc32d4f006c0332c54f4cf0797fd93c2e4b3e/internal/service/ec2/ec2_instance.go#L946-L949

    Reproduction

    1. Create an organization member using Terraform.
    2. Remove the member from the Auth0 management UI.
    3. terraform plan
    4. 💥

    Auth0 Terraform Provider version

    0.40.0

    Terraform version

    1.3.5

    bug 
    opened by haines 0
Releases(v0.41.0)
auth0 is a package helping to authenticate using the Auth0 service.

auth0 auth0 is a package helping to authenticate using the Auth0 service. Instal

GREAT BEYOND 0 Jan 13, 2022
Go client library for the Auth0 platform.

Auth0 Go SDK Go client library for the Auth0 platform. Note: This SDK was previously maintained under go-auth0/auth0. Table of Contents Installation D

Auth0 50 Dec 30, 2022
auth0 jwt validator with jwks caching

JWT Validator for Auth0 (https://auth0.com/) that caches public JWKS (since there is a limit on calls to public JWKS URL) Example securing a GraphQL s

null 0 Mar 4, 2022
Terraform Provider authentik

This Provider is in technical preview, resources and fields are subject to change. Terraform Provider authentik Run the following command to build the

authentik 25 Dec 14, 2022
Create the Provider for Zoom API and automate the creation of zoom user using terraform.

Create the Provider for Zoom API and automate the creation of zoom user using terraform.

ashish dhodria 3 Sep 7, 2022
Terraform utility provider for generating Time-Based One-Time Passwords (TOTPs)

Terraform TOTP Provider The TOTP provider is a utility provider, which allows for generating Time-Based One-Time Passwords (TOTP) following the RFC 62

null 3 Nov 19, 2022
simple-jwt-provider - Simple and lightweight provider which exhibits JWTs, supports login, password-reset (via mail) and user management.

Simple and lightweight JWT-Provider written in go (golang). It exhibits JWT for the in postgres persisted user, which can be managed via api. Also, a password-reset flow via mail verification is available. User specific custom-claims also available for jwt-generation and mail rendering.

Max 31 Dec 18, 2022
Scaffold to help building Terraform Providers using AWS IAM authentication.

Terraform Provider Scaffolding This repository is a template for a Terraform provider. It is intended as a starting point for creating Terraform provi

Paul Zietsman 1 Mar 31, 2022
Go library providing in-memory implementation of an OAuth2 Authorization Server / OpenID Provider

dispans Go library providing in-memory implementation of an OAuth2 Authorization Server / OpenID Provider. The name comes from the Swedish word dispen

Xenit AB 3 Dec 22, 2021
An implementation for an OpenID Connect Provider in Go.

oidc-go This is an implementation of an OpenID Connect Provider (OP) as defined by OpenID that is meant to be a full, production ready OP. Features: E

Anish Sinha 5 Oct 7, 2022
Identity-service - An OAuth2 identity provider that operates over gRPC

Identity-service - An OAuth2 identity provider that operates over gRPC

Otter Social 2 May 2, 2022
Identity - An OAuth2 identity provider that operates over gRPC

Otter Social > Identity Provider An OAuth2 identity provider that operates over

Otter Social 2 May 2, 2022
A simple passwordless authentication middleware that uses only email as the authentication provider

email auth A simple passwordless authentication middleware that uses only email as the authentication provider. Motivation I wanted to restrict access

Miroslav Šedivý 5 Jul 27, 2022
Platform-Agnostic Security Tokens implementation in GO (Golang)

Golang implementation of PASETO: Platform-Agnostic Security Tokens This is a 100% compatible pure Go (Golang) implementation of PASETO tokens. PASETO

Oleg Lobanov 659 Jan 2, 2023
Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform based on OAuth 2.0 / OIDC.

A UI-first centralized authentication / Single-Sign-On (SSO) platform based on OAuth 2.0 / OIDC

Casbin 4.8k Dec 29, 2022
ZITADEL - Identity Experience Platform

What Is ZITADEL ZITADEL is a "Cloud Native Identity and Access Management" solution built for the cloud era. ZITADEL uses a modern software stack cons

CAOS 2k Jan 1, 2023
Generate and verify JWT tokens with Trusted Platform Module (TPM)

golang-jwt for Trusted Platform Module (TPM) This is just an extension for go-jwt i wrote over thanksgiving that allows creating and verifying JWT tok

null 4 Oct 7, 2022
auth0 is a package helping to authenticate using the Auth0 service.

auth0 auth0 is a package helping to authenticate using the Auth0 service. Installation go get github.com/auth0-community/go-auth0 Client Credentials

Paulus Robin 1 Feb 15, 2022
auth0 is a package helping to authenticate using the Auth0 service.

auth0 auth0 is a package helping to authenticate using the Auth0 service. Instal

GREAT BEYOND 0 Jan 13, 2022
Terraform-provider-e2e-network - Terraform Provider Scaffolding (Terraform Plugin SDK)

This template repository is built on the Terraform Plugin SDK. The template repository built on the Terraform Plugin Framework can be found at terraform-provider-scaffolding-framework.

eSadhana 0 Jan 19, 2022