Catch risky Auth0 sign-ins with location and VPN checks

Watch my Auth0 tenant for new log events and triage risky sign-in activity as it happens. Use the Auth0 poll trigger on new log events so each event is handled as it is written to the tenant log.

I only care about events that could indicate an account under attack: failed logins (Auth0 type codes f, fp and fu), accounts blocked by brute force protection (limit_wc and the other limit_ codes), and failed or suspicious signups (fs and ss). Ignore every other event type, including ordinary successful logins and logouts, and do not open an investigation for them.

For each risky event, take the IP address on the event and enrich it. Call IPinfo Get Full IP Details to resolve the city, region, country and the network owner, remembering that the org field combines the ASN and the organization name, for example AS15169 Google LLC. Then call the IPinfo Core / Plus IP Lookup to read the privacy detection flags that reveal a VPN, proxy, Tor exit node, relay or hosting range.

IPinfo gates the privacy flags behind a paid plan and omits plan-gated fields rather than failing the request, so treat them as optional. If the privacy block comes back absent, or the call returns a 403, carry on with the geolocation and network owner alone and say in the alert that privacy flags were unavailable, rather than dropping the event. If the event carries no IP address, or IPinfo returns bogon true for a private or non routable address, skip enrichment and do not raise an alert on that event by itself.

Before deciding anything, establish what normal looks like for that user. Use Auth0 Search Log Events to fetch the same user's recent successful logins (type code s) from roughly the last 30 days, and note the cities, countries and network owners they usually connect from, along with the timestamp and location of the most recent one.

Now judge the event rather than pattern matching on it. Treat it as genuinely risky when the evidence points at something other than a routine mistake: an anonymised source such as a VPN, proxy or Tor exit node, or a hosting or data center range where a real person would not normally originate; impossible travel, meaning a country or distant city that could not plausibly be reached in the time since that user's last successful login elsewhere; a first time country combined with a failed login or a lockout; or a blocked account with repeated failures from an unfamiliar network. Stay quiet for ordinary noise, above all a mistyped password from the user's usual city on their usual internet provider, which needs no message at all.

Post exactly one Slack message per risky event to my security channel using the Slack Bot Send a Message action. Keep it to a few lines of Slack mrkdwn: the user (email where available, otherwise the Auth0 user id), what happened in plain words, the resolved city and country, the network owner, the privacy flags or a note that they were unavailable, how this compares with the user's recent successful logins, and a one line recommendation such as monitor, force a password reset, or block the address. Do not post anything when nothing risky was found, and never post an all clear or a summary of quiet periods, so the channel keeps its signal.