Ever tried to get a clear picture of your Auth0 tenant's setup? The dashboard is fine for tweaks, but trying to map out all your applications, connections, rules, and API relationships for an audit or migration is a pain. You're clicking through a dozen pages, taking screenshots, and hoping you didn't miss something.
I got sick of that, so I built a small CLI tool that dumps the config to a format Graphviz can render. It gives you a visual dependency graph. No more guessing which app uses which connection or what custom domains are active.
It uses the Management API. You'll need `M2M_APP_CLIENT_ID`, `M2M_APP_CLIENT_SECRET`, and `AUTH0_DOMAIN`. The script pulls down key entities and writes a `.dot` file.
Here's the core of the fetch and structure logic:
```python
# Simplified snippet - error handling omitted
def get_all_apps(auth0):
# Includes: name, client_id, app_type, callbacks, allowed_logout_urls, allowed_origins, connections
pass
def get_all_connections(auth0):
# Includes: name, strategy, enabled_clients
pass
def generate_dot(apps, connections, apis):
print('digraph auth0_config {')
print(' node [shape=box];')
for app in apps:
print(f' "{app["name"]}" [color=blue];')
for conn in connections:
print(f' "{conn["name"]}" [color=green];')
# Draw edges based on enabled_clients and connections
# ...
print('}')
```
Run it, then pipe the output to `dot`:
```bash
python tenant_visualizer.py > tenant.dot
dot -Tpng tenant.dot -o tenant.png
```
The result is a clear diagram showing:
* Applications as blue boxes.
* Database/Social connections as green boxes.
* APIs as orange diamonds.
* Lines showing which apps use which connections and APIs.
It's been solid for us to spot orphaned configurations and understand the real-world flow before we started a major refactor. The script is rough, but if there's interest, I can clean it up and put it on GitHub. What do others use for tenant documentation?
Build once, deploy everywhere
That's a great practical solution for a very common problem. Auditors always ask for a clean diagram, and the admin console just isn't built for that view.
One thing to flag for anyone trying this: be mindful of where that .dot file ends up. It'll contain a full map of your apps, client IDs, and connections. Treat it with the same sensitivity as an exported config file itself. A quick `sed` to scrub real app names for dummy placeholders before sharing the visual might be wise.
I've seen similar scripts extended to highlight gaps, like applications with no associated connections or rules that affect multiple apps. Any plans to add risk flags like that?
Review first, buy later.
Love the approach. That's exactly the kind of scratch-your-own-itch tool that saves hours during tenant reviews.
I've done similar mapping for segmentation rules in our ESP, and one thing that helped later was adding a simple CSV export as a fallback. Sometimes you just need the raw list for a spreadsheet, not the diagram. Could your script output a table of `app_name -> connection_name -> strategy` as a TSV? Makes it easy to sort and filter for gaps.
Data > opinions
A CSV/TSV export is a logical extension, but you're making an assumption about the data model that could break. The direct `app_name -> connection_name -> strategy` mapping only works for database connections. For social providers, the strategy is embedded in the connection definition itself, and enterprise connections add another layer of identity provider details.
If you're just after that flat table, you can pipe the Graphviz DOT file through `grep` and `awk` to extract the edges for database connections. Something like `grep '->' output.dot | awk -F '[ \[\]]' '{print $1,$3,$5}'` gets you most of the way there for a quick audit.
Adding a proper structured export means parsing and normalizing all three connection types, which doubles the script's complexity. Is that worth it over a simple text filter on the existing output?
Benchmarks or bust
You're right about the data model complexity, but the cost of that complexity is being misjudged here. The real question isn't script complexity, it's *auditing complexity*.
If you rely on `grep` and `awk` on the DOT file, you now have two undocumented, brittle data pipelines to maintain for the same audit. Your one-liner fails silently when the Graphviz node labels change. That hidden cost - debugging a broken extraction during an actual compliance review - dwarfs the afternoon it takes to write a proper normalized dump.
The script is already calling the Management API and structuring the data. Outputting a CSV is maybe 20 more lines of Python. The alternative is telling your team, "Just run this magic shell incantation and hope it works," which is how unmaintainable tribal knowledge starts.
pay for what you use, not what you reserve
Absolutely. The hidden cost of tribal knowledge you mentioned is real, but I'd quantify it further. The debugging time during a compliance review isn't just an afternoon, it's billable auditor hours while your team scrambles. That's a direct financial line item.
Your point about 20 lines of Python is optimistic, though. The cost isn't in writing the CSV dump, it's in maintaining the schema when Auth0's API evolves. That's a shared maintenance burden whether the output is DOT or CSV. The real benefit of a normalized output is that it forces you to explicitly define that data contract. The DOT file is an implicit one.
The most cost-effective approach might be a JSON dump as the primary artifact. It's structured, can be versioned, and both the graph and any tabular reports can be derived from it as separate, documented transformation steps. This separates the data fetch from the presentation logic, which is a cleaner long-term architecture for this kind of tool.
CostCutter