Spot duplicate and throwaway Auth0 accounts by network

Build me a trust and safety board for spotting duplicate and throwaway accounts in our Auth0 tenant. The people using it are growth and trust and safety, and the job they open it for is the weekly free trial abuse review: which accounts that signed up recently came from the same place, and which of those groups are real abuse rather than one office or one school.

The main view is a cluster board. Load recent signup and login activity with Auth0 Search Log Events across a window the user picks (default the last seven days), and pull the matching account records with Auth0 Search Users so every account carries email, signup date, last login, login count and current block status. Collect every distinct source IP from those events and enrich them in one pass with IPinfo Batch IP Lookup. For each distinct network that comes back, call IPinfo Get ASN Details once so the board knows the network owner, its type and its country.

Group the accounts into clusters two ways: by exact IP address, and by the owning network (ASN). Cluster on the network as well as the address, because abusers rotate addresses inside one hosting provider and an IP-only view misses them entirely. Each row shows the cluster key, how many accounts are in it, the network owner name, the countries seen, the first and last signup date in the group, and a risk column carrying the VPN, proxy, Tor, relay and hosting flags from IPinfo Core / Plus IP Lookup. Sort by account count descending, and let the user filter by minimum cluster size so small groups stay out of the way.

Next to every cluster, show a plain language explanation of what kind of network it is: home internet provider, mobile carrier, business or education network, cloud hosting or datacenter, or VPN and proxy. This is the most important column on the screen, because it is the difference between a school computer lab and a trial farm. Eleven accounts on a residential ISP is usually a shared office or campus and should rank low. Eleven accounts on a cloud hosting network is almost never a real customer and should rank at the top. Put that reasoning in the interface in words, not just a number.

IPinfo privacy detection and company data are paid plan features. When they are absent, degrade gracefully to country plus network owner and label the risk column as unavailable on the current plan, rather than rendering a blank that reads as clean. Clustering by network has to keep working on the free tier.

Opening a cluster lists every account in it with email, signup date, last login, login count, country and current block status. From that list the user can block an account with Auth0 Update User by setting its blocked flag, clear a false positive with Auth0 Unblock User, and remove an account with Auth0 Delete User. Block is the default and the prominent button because it is reversible. Delete sits behind an explicit confirm step that names the account being removed. Refresh a row with Auth0 Get User after any change, since search results lag behind writes by a few seconds.

The user saves a verdict on the whole cluster: confirmed abuse, false positive, or watch, along with a short note, who reviewed it and when. Persist those verdicts in the app so a reviewed cluster does not resurface on the main board next week. Keep a filter for revisiting reviewed clusters, and if a cluster that was previously cleared picks up a batch of new accounts, bring it back with a note saying it changed.

Add a "Check this cluster" button that starts a background agent. The agent reads each account's history with Auth0 Get User Logs, collects every IP that appears across those logins, enriches them with IPinfo Batch IP Lookup and IPinfo Core / Plus IP Lookup, and resolves the owning networks with IPinfo Get ASN Details. It then writes a short case note back into the app, attached to the cluster, saying which pattern this looks like: shared office wifi, a corporate VPN, a mobile carrier sharing one address across many customers, or genuine trial abuse. The note should give the two or three facts that decided it (for example, all eleven accounts share one business network and only ever log in on weekdays) plus a recommended action. Show the note in the cluster detail view, with a running state while the agent works and the finished note when it lands.

When a cluster is marked confirmed abuse, post it to a Slack channel using the Slack Bot Send a Message operation so the growth team sees what was cut and why. The message names the network and its owner, how many accounts were in the cluster, how many were blocked and how many deleted, the country spread, and a line or two from the case note explaining the call. Let the user choose the channel in settings, and only post on confirmed abuse, never on false positives or watch verdicts.

Practical notes: Auth0 log reads are rate limited and page through a checkpoint, so fetch the window once, cache it for the session, and give the user an explicit refresh control instead of refetching on every interaction. Batch the IP enrichment rather than looking addresses up one at a time, and cache network lookups since many accounts in a cluster share the same network. Skip private and non routable addresses. Show the last refresh time on the board.