legacy_custom_claims flag on auth0_tenant resource

[nialdaly]

Checklist

• I agree to the terms within the Auth0 Code of Conduct.

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).

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!

• Custom Claims Migration
• Legacy custom claims

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

[sergiught]

Hey @nialdaly 👋🏻 thanks for raising this with us.

The manage.auth0.com/api/tenants/settings should still be able to toggle that flag on and off by including it in the flags section of the payload. We would simply need to add support within the go-auth0 SDK first and then this provider. Similar to auth0/go-auth0#80 and #208.

I don't have an ETA available for you for when we could start tackling this, as right now we're focusing on #14, but contributions are more than welcomed as well!

[nialdaly]

Thanks! @sergiught I have raised a PR in auth0/go-auth0. Happy to make the change in terraform-provider-auth0 when the Go client library is ready.

[sergiught]

Hey @nialdaly thanks a lot! That's highly appreciated! Would you mind actually raising the terraform-provider-auth0 PR as well even without the auth0/go-auth0#114 counterpart being merged? Just so we can validate the approach E2E against your tenant as well.

To do so you can temporarily in the go.mod run go get github.com/auth0/go-auth0@f6efb4624c4fdf58bb315437d37db8577975a561 to fetch the version from your go-auth0 PR and build the terraform provider PR with that.

After you've finished doing so you can simply run make install VERSION=0.38.0 (or however you wanna tag it) and then use it in your terraform config file as such:

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

provider "auth0" {
  debug = "true"
}

The first thing that terraform checks is if there are any versions of the provider locally, and only after fetches them from the public registry.

I can also help out with the http test recordings if you have issues updating those to make the tests pass as well.

Let me know if you have any questions:)

[nialdaly]

Thanks for the guidance! @sergiught I followed the steps above and made a new personal-use Auth0 tenant (on the free subscription plan, I use Auth0 for work which is where I noticed this) and tested the provider. The result is below.

Based on what I've seen at work, when the Custom claims must be namespaced flag is toggled, a PATCH request is sent to https:/manage.auth0.com/api/migrations with a payload of the form:

{flags: {legacy_custom_claims: false}}

Conversely, when the Disable clickjacking protection for Classic Universal Login flag is toggled, a PATCH request is sent to https://manage.auth0.com/api/tenants/settings with the following payload:

{flags: {disable_clickjack_protection_headers: false}}

Would it be be an issue that the legacy_custom_claims flag doesn't seem to be available on the tenants resource?

[sergiught]

Hey @nialdaly thanks for pushing through with this 💪🏻

As far as I know the migrations section in the UI, should still use the PATCH on tenants/settings.

But it depends on the specific tenant if the request will go through or not, as not all the tenants have the same flags available.

Have you tried to toggle the flag through terraform on your companies Auth0 Tenant?

[nialdaly]

Thanks! @sergiught Yes, the personal Auth0 tenant doesn't have the Custom claims must be namespaced flag available which could also be an issue. I'll see if I can replicate the experiment (with the changes made to go-auth0 and terraform-provider-auth0) on a new experimental Auth0 tenant at work on Tuesday!

[nialdaly]

Hey @sergiught I was able to test this today using a tenant with Custom claims must be namespaced flag available and it also didn't work. The error was the same as before:

│ Error: 400 Bad Request: Payload validation error: 'Additional properties not allowed: legacy_custom_claims' on property flags (Flags used to change the behavior of this tenant).
│ 
│   with auth0_tenant.test_tenant,
│   on main.tf line 17, in resource "auth0_tenant" "test_tenant":
│   17: resource "auth0_tenant" "test_tenant" {

Is there a way to confirm that the legacy_custom_claims flag is available on the tenants/settings in the Auth0 Management API?

[sergiught]

Hey @nialdaly 👋🏻 thanks a lot for following up on this. As far as I know this should have worked if the tenant has that flag within the migrations section in the UI. Let me follow up internally with the team responsible for the tenant flags and find out what's happening. I'll circle back here once I have more info. Appreciate your patience 🙏🏻

[nialdaly]

Thank you! @sergiught

[sergiught]

Hey @nialdaly 👋🏻 , I really appreciate the back and forth we had so far and for initiating those changes within the Go SDK and the Terraform provider! Apologies it took a while to get back to you, here's what I found:

Unfortunately even tho the flag is listed under the Migrations section and the other flags in that same section being available on the flags property of the tenant (managed through PATCH */tenants/settings), this specific legacy_custom_claims is flagged as deprecated and will be removed very soon so it can only be managed through the admin endpoints of the management API. Please also check: https://auth0.com/docs/troubleshoot/product-lifecycle/deprecations-and-migrations#legacy-custom-claims.

Unfortunately we won't be able to support this flag within the Provider 😢 and as such we'll have to close this issue down.

If you have any other feedback for us so we can improve the provider please don't hesitate to bring it forward. We really wanna keep improving everyone's experience with it.

[nialdaly]

Hi @sergiught no worries at all, thanks for getting back to me! Cheers!