Add auth0-python Auth0 Management API provisioning helpers

[IamJeffG]

Goal

Automate Auth0 setup in order to speed deploying the Guardian Connector stack. This includes:

• Auth0 per-app clients
• RBAC roles
• Post-login action

This PR adds code that talks directly to the Auth0 Management API, instead of requiring the human operator to click through Auth0's web portal by hand. It automates most of the steps already documented in auth0/README.md.

PR Stack

This PR is the first of two in a stack:

1. Auth0 provisioning library (no UI)
2. Expose auth0 automation via a new gc-stack-deploy wizard subcommand.

What I changed and why

This PR is pure auth0 client library code. Not yet exposed on the CLI or TUI.

Note that a prerequisite for all this is a human operator still must manually create the Auth0 Tenant and an M2M ("Machine-to-Machine") app in the Auth0 portal. gc-stack-deploy is the M2M app; this M2M app will be used only to bootstrap the rest of the Auth0 tenant, and then it'll never be used again after deployment.

This PR adds two just 2 Python modules (and tests):

• wizard/auth0/client.py: very thinly wraps auth0-python.
  • authenticates the M2M app (populates args for GetToken, calls client_credentials`)
  • Not every Management API collection supports server-side name search, so lookup helper find_by_name lists everything and matches client-side.
• wizard/auth0/provisioning.py: declarative ensure_* functions, one for each resource type we want to ensure got created:
  • google-oauth2 connection, per-app clients, the M2M "GC Metrics" client, Management API grants, Admin/Member/Guest/SignedIn roles, and both Post-Login Actions
  • Every one lists resources, calls our find_by_name helper, and updates-or-creates (idempotent).
  • The Management API only returns client_secret on the create response, but not on later reads. So ensure_client takes an existing_secret param so a caller can pass through a secret already known from the target stack.yaml, and returns None (with a warning) when no secret is known.

Note that auth0 clients for GC Metrics and Windmill are created even though there's no field for them in stack.yaml. Their ID and secrets simply get logged for the operator to write down for later.

Note for reviewers

Half the diff is tests. The reason provisioning.py is so long is because it's pretty much enumerating a slew bunch of business rules. It's the number of business rules that drives the size of this PR.

$ git diff main..HEAD --stat
 caprover/gc-stack-deploy/pyproject.toml                                   |   1 +
 caprover/gc-stack-deploy/src/gc_stack_deploy/wizard/__init__.py           |   0
 caprover/gc-stack-deploy/src/gc_stack_deploy/wizard/auth0/__init__.py     |   0
 caprover/gc-stack-deploy/src/gc_stack_deploy/wizard/auth0/client.py       |  36 +++++++++
 caprover/gc-stack-deploy/src/gc_stack_deploy/wizard/auth0/provisioning.py | 262 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 caprover/gc-stack-deploy/tests/wizard/__init__.py                         |   0
 caprover/gc-stack-deploy/tests/wizard/auth0/__init__.py                   |   0
 caprover/gc-stack-deploy/tests/wizard/auth0/provisioning_test.py          | 252 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 551 insertions(+)

What I'm not doing here

I think there may be a mismatch in role names given in the documentation:

gc-deploy/auth0/README.md

Line 112 in 99c86f2

Role-Based Access Control (RBAC) allows you to control user access to different features based on assigned roles. Several of the Guardian Connector applications (e.g. GC Explorer and GC Landing Page) use four roles: **Admin**, **Member**, **Viewer**, and **Public**.

Viewer, Public

vs

gc-deploy/auth0/README.md

Lines 136 to 140 in 99c86f2

	2. Click **"+ Create Role"** and create the following roles:
	- **Admin**: "All routes including `/config`"
	- **Member**: "Restricted routes (cannot access `/config`)"
	- **Guest**: "Guest and unrestricted routes only"
	- **SignedIn**: "can access only routes that are set to public"

Guest, SignedIn

In this PR I used the latter list: Guest and SignedIn. But have not (yet) fixed the mismatch until @rudokemper confirms it is incorrect and I'm keeping the right one.

LLM use disclosure

Written almost entirely in claude code, including the plan and code. I reviewed the plan and made many iterations of the code. I reviewed the my code to my satisfaction, including minor edits myself.

[conservationtimothy]

deploy can return before the action version has finished building. Since ensure_post_login_actions binds immediately after both deploy calls, this could intermittently fail with Auth0 reporting that the action has not been deployed yet.

The current tests don’t catch this because mgmt is mocked and deploy returns immediately. We should wait until each action version is built before calling update_many.

Auth0 also documented this issue in 2025: https://support.auth0.com/center/s/article/Trying-to-create-a-binding-for-an-action-that-has-not-been-deployed-yet