Apply Advanced Threat Detection checks to other operations

[zoefarrell]

Apply Advanced Threat Detection checks to other operations

Problem

Advanced Threat Detection is only evaluated during password logins, not during: token refresh, passwordless logins, OTP logins, and WebAuthn logins. In the case of token refresh, this creates a gap where an attacker who already has valid tokens can keep refreshing them even after a threat is detected.

For example, with “impossible travel,” the attacker logs in from Location A and gets tokens. When the real user logs in from Location B, the threat rule blocks them — but the attacker can still refresh their token and stay logged in.

In short, threat detection can block new logins but can’t revoke or stop existing sessions once tokens have been issued.

Solution

Extend Advanced Threat Detection checks to other login types and token refresh operations so that threat conditions detected during refresh also trigger appropriate security responses (blocking the refresh, requiring step-up authentication, etc.).

This would allow organizations to mitigate compromised sessions more quickly by ensuring that detected threats affect both new login attempts and existing token refresh flows.

Alternatives/workarounds

Currently, the only way to invalidate compromised tokens is through manual intervention (revoking refresh tokens) or waiting for token expiration. Organizations must rely on very short token lifetimes to minimize exposure windows, which impacts user experience.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.