Before
Security staff likely had to monitor token-delivery events, search recent user activity, compare IP addresses and locations, and determine manually whether travel between logins was plausible. They also had to notify IT security, coordinate the response, revoke application access, reset the account password, and document the outcome across separate tools.
How it works
- Receive and deduplicate OAuth token events, then record new activity for investigation.
- Compare the current login with recent application activity and evaluate IP location, travel distance, and known-IP conditions.
- Notify IT security with contextual actions, then either close the alert or revoke tokens, reset the account password, and update the incident.
Workflow details
- Event intake and filtering: The workflow starts when a webhook receives an OAuth token delivery event containing the application, user, IP address, client type, scopes, location data, and event timestamp. It waits 10 seconds, filters for relevant monitoring events, and avoids processing duplicate activity by comparing the event against previously recorded token issuance times.
- Activity and location analysis: For a new event, the workflow retrieves up to 20 recent token activities for the same user and application. It records the event in a spreadsheet, compares the current IP with previous login IPs, enriches the relevant IP addresses with country, region, city, and coordinates, and calculates the distance between the current and prior locations.
- Suspicion decision: The workflow distinguishes known IP activity from unfamiliar access and checks for impossible-travel indicators, including different countries or cities, a distance of at least 50 km, or an unavailable distance result. Activity that remains within the same country and town and under the configured distance threshold can be marked as having passed the checks.
- Security notification and decision: When the event requires review, the workflow sends a Slack alert to IT security with the application, user, flagged and previous IP addresses, locations, travel distance, scopes, and client type. The alert includes actions for an authorized responder to approve the token or revoke it.
- Remediation and closure: If revocation is selected, the workflow removes the user’s application access tokens, generates a temporary password, updates the user account, forces a password change, and requires a change at the next login. It then updates the original alert with the outcome; approved or otherwise resolved cases can be closed or archived, while activity and timestamps remain recorded.
What changed
Each monitored event is now filtered, deduplicated, logged, and evaluated automatically before reaching IT security. The team receives one contextual alert with the relevant evidence and retains the human decision to approve or revoke the token, while the selected remediation and incident update are executed as a coordinated sequence.
Work removed
Monitoring token-delivery events one by one, checking for duplicate timestamps, retrieving recent application activity, comparing current and previous IP addresses, looking up IP locations, calculating travel distance, assembling security notifications, copying outcomes into records, and manually performing the token revocation and forced password-change sequence.
Expected outcome
A conservative expectation is that at least five recurring manual checks or handoffs per flagged event are replaced with automated triage, while suspicious cases receive a documented security decision and, when authorized, coordinated token and account remediation.
