Skip to content

auth0_branding with only logo_url silently resets authentication profile settings #1510

New issue
New issue
Open
Open
auth0_branding with only logo_url silently resets authentication profile settings#1510
Assignees
KartikJha

Description

@Asarew
Asarew
opened on Mar 19, 2026
Contributor

Checklist

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

Description

Adding an auth0_branding resource with only logo_url set resets the tenant's authentication profile (identifier_first) back to "Identifier + Password." The authentication profile was configured as "Identifier First" via the dashboard and is not managed by Terraform (no auth0_prompt resource in the config).

I checked the provider source -- auth0_branding correctly uses PATCH with omitempty, so the actual request is just:

PATCH /api/v2/branding
{"logo_url": "https://example.com/logo.svg"}

The provider code has no interaction with /api/v2/prompts at all. The reset happens server-side. This is the same Auth0 Management API bug reported and confirmed by multiple users on the deploy CLI side (auth0/auth0-deploy-cli#842).

The impact is worse in Terraform because auth0_branding and auth0_prompt are separate resources with no guaranteed execution order. Even if both are declared, the branding PATCH may run after the prompt PATCH, undoing it. If auth0_prompt is not declared at all (common when authentication profile was set via the dashboard), the reset is silent and permanent.

Related issues:

Expectation

PATCH /api/v2/branding with only logo_url should update the tenant-level logo. It should not affect settings under /api/v2/prompts, specifically identifier_first.

Reproduction

  1. Configure the authentication profile to "Identifier First" via the Auth0 dashboard (Authentication > Authentication Profile)
  2. Do not have an auth0_prompt resource in your Terraform config
  3. Add an auth0_branding resource with only logo_url:
resource "auth0_branding" "my_brand" {
  logo_url = "https://example.com/logo.svg"
}
  1. Run terraform apply
  2. Check Authentication > Authentication Profile in the dashboard -- it has been reset to "Identifier + Password"

This is consistently reproducible. The workaround (confirmed by deploy CLI users) is to either exclude branding or ensure prompt settings are applied after branding.

Auth0 Terraform Provider version

= 1.34

Terraform version

= 1.14.0

Activity

Asarew
added a commit that references this issue on Mar 20, 2026

fix: preserve prompt settings across branding updates

e30a579

Asarew commented on Mar 20, 2026

@Asarew
Asarew
on Mar 20, 2026
ContributorAuthor

Reproduction confirmed with raw API calls

I validated this is an Auth0 Management API bug. Reproduction using only curl:

# Prerequisites:
# - An M2M app with read:prompts and update:branding scopes
# - identifier_first set to true via the dashboard (Authentication > Authentication Profile)

# 1. Read prompt settings BEFORE
curl -s "https://$AUTH0_DOMAIN/api/v2/prompts" \
  -H "authorization: Bearer $TOKEN"

# 2. PATCH branding with only logo_url
curl -s -X PATCH "https://$AUTH0_DOMAIN/api/v2/branding" \
  -H "authorization: Bearer $TOKEN" \
  -H 'content-type: application/json' \
  -d '{"logo_url":"https://example.com/logo.svg"}'

# 3. Read prompt settings AFTER
curl -s "https://$AUTH0_DOMAIN/api/v2/prompts" \
  -H "authorization: Bearer $TOKEN"

Results:

Before PATCH /api/v2/branding:

{
    "universal_login_experience": "new",
    "identifier_first": true,
    "webauthn_platform_first_factor": false
}

After PATCH /api/v2/branding:

{
    "universal_login_experience": "new"
}

Both identifier_first and webauthn_platform_first_factor are completely removed from the response after a branding PATCH that only contains logo_url. The branding PATCH response itself is correct (returns only {"logo_url": "..."}) -- the side effect is entirely server-side on the /api/v2/prompts state.

Asarew commented on Mar 20, 2026

@Asarew
Asarew
on Mar 20, 2026
ContributorAuthor

Given that this is an API-level bug, should the provider work around it in the meantime? A minimal fix would be to save and restore prompt settings around branding updates in updateBranding:

  1. GET /api/v2/prompts before the branding PATCH
  2. PATCH /api/v2/branding (triggers the bug)
  3. PATCH /api/v2/prompts with the saved state to undo the reset

Example: commit

KartikJha
self-assigned this
on Mar 25, 2026

saltukalakus commented on Mar 25, 2026

@saltukalakus
saltukalakus
on Mar 25, 2026

The same issue was reproducible in Auth0 CLI. There is a resent fix on it here.

KartikJha commented on Mar 26, 2026

@KartikJha
KartikJha
on Mar 26, 2026
Contributor

@Asarew thanks for raising the issue, have verified the management API issue on my end, @duedares-rvj please provide a second review.

@Asarew we are raising the issue internally with out API team, kindly watch this thread for the updates!

Thanks!

Asarew commented on Apr 23, 2026

@Asarew
Asarew
on Apr 23, 2026
ContributorAuthor

@saltukalakus The fix you suggested on the cli looks more like a workaround.

@KartikJha Any updates to share already?

FaranIdo
mentioned this on May 8, 2026
anubhav06
mentioned this on Jun 12, 2026

Asarew commented on Jun 16, 2026

@Asarew
Asarew
on Jun 16, 2026
ContributorAuthor

@duedares-rvj Do you have some insight on when we can expect this issue to be fixed?

harshithRai
mentioned this on Jun 17, 2026

StephenWithPH commented on Jul 9, 2026

@StephenWithPH
StephenWithPH
on Jul 9, 2026

We hack around the same problem via:

resource "auth0_prompt" "prompts" {
  # Order the prompt after branding so identifier-first is (re)asserted in any
  # run that also writes branding -- guards Auth0 provider bug #1510, where an
  # auth0_branding apply can silently flip the auth profile to combined
  # identifier and password.
  depends_on = [auth0_branding.this]
}

... but would very much like to see this bug fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @Asarew@saltukalakus@StephenWithPH@KartikJha

      Issue actions