Update:clients permission required for Login page

Get Help
,
1

Hi,

When using the Auth0 Deploy CLI which interacts with the default Management API, we’re trying to reduce the number of permissions it has.

It seems like update:clients is required for the login page. ie in tenant.yml

pages:
  - name: login
    enabled: false
    html: ./pages/login.html

Looking through the source code, the src/tools/auth0/handlers/pages.ts from auth0-deploy-cli has this which I believe is the culprit.

        await this.client.clients.update(globalClient[0].client_id, {
            custom_login_page: page.html,
            custom_login_page_on: page.enabled,
        });

Could this potentially be decoupled from the update:clients permission?

3

Hi @jarren.ong

Welcome to the Auth0 Community!

The update:clients permission is strictly required when managing the pages configuration (specifically the Classic Universal Login page) via the Auth0 Deploy CLI. This is due to how the Classic Universal Login architecture associates the custom HTML with a hidden “Global Client” at the tenant level.

When you define a custom login page using the pages block in your tenant.yml , the Deploy CLI maps this to the custom_login_page and custom_login_page_on properties of that Global Client. Because the CLI must make a PATCH request to the Management API’s /api/v2/clients/{id} endpoint to update these specific properties, the Management API enforces the update:clients scope.

Because this is a hard requirement of the Management API endpoint being called, there is no way to remove the update:clients scope while continuing to manage the pages: - name: login block via the Deploy CLI.

Depending on your strictness for the principle of least privilege, you have two paths forward:

  • If you are strictly bound to the Classic Universal Login experience (e.g., you have highly custom JavaScript running in the login page HTML), you must retain the update:clients scope for the Machine-to-Machine (M2M) application that your Deploy CLI uses.
  • If you are looking to decouple your page customization from your client configurations, we highly recommend migrating to the New Universal Login .
    → New Universal Login uses a different architecture centered around the branding configuration, rather than the pages configuration.
    → In the Deploy CLI, you manage New UL templates using the branding block (specifically branding_templates ).
    → This utilizes scopes like update:branding , keeping it entirely separate from your application client configurations.

If you have any other questions, let me know!

Kind Regards,
Nik

4

Hey Nik,

That makes sense and yeah seems to have done the trick. Thanks very much!