Protecting against bots, fraud and abuse
Radar adds automated protections on top of AuthKit by collecting signals on the behavior of users as they sign in to your app. These signals feed into an engine that identifies abusive or anomalous behavior. When Radar detects a suspicious authentication attempt, it can block or challenge that attempt based on the settings you configure.
Radar leverages device fingerprinting to identify which client is being used to authenticate with AuthKit. This enables Radar to differentiate between legitimate and malicious users, so that automated protections won’t impact your app’s availability during an attack. It’s also a signal for suspicious behavior, such as when a device is used for multiple accounts or multiple devices are using the same account.
Radar is not enabled for all AuthKit instances by default. If you would like to access this feature, please reach out to our team, or for current customers, drop a note in your shared Slack channel.
Radar’s dashboard provides a summary of authentication activity in your app. The top chart shows counts of suspicious events that Radar is detecting, along with automated actions that Radar took based on configuration. The counts are updated in real time to make it easy to spot spikes in anomalous behavior. To see historical trends, the time range for the chart can be toggled between 24 hours, 7 days and 30 days.
Below the top chart is a set of cards that show Radar detection activity for different user identifiers. This is helpful to understand which types of devices, locations, users, etc. have been detected most often by Radar. Each card is linked to the events page to drill into a list of individual event activity.
A complete list of Radar events appears under the “Events” tab. This list can be filtered by detection type, action taken, or a specific user ID or email. By clicking into a single event, you can view all of the metadata related to that action including device, location, user agent and IP address. Reviewing events in Radar can help inform when custom restrictions may be useful, such as allowing a known legitimate user to bypass detections, or blocking an IP range that is abusing your sign-in.
Radar gives you full control over the automated actions that are taken to suppress suspicious activity. By enabling a detection, you can choose to block or challenge an authentication attempt that exhibits the detection’s behavior.
Blocking an attempt will cause the authentication to fail, even if valid credentials are provided. The user will see a message indicating their sign-in was not successful, and can reach out to an administrator for more detail.
Challenging an attempt will send the user an email with a one-time passcode (OTP). The user is then prompted to enter that code to continue authentication. Challenging suspicious authentication attempts with an OTP is effective in stopping bots that are capable of solving CAPTCHAs, as well as malicious users who have stolen credentials but don’t have access to the user’s email account.
Notifying on an attempt will send an informational email to users and/or admins when Radar detects a suspicious behavior. This is helpful to proactively make individuals aware that an attack might be taking place, or their account was compromised.
Out of the box, Radar ships with the following detections:
Block or challenge sign-in attempts that are initiated by a bot or program.
In addition to detecting that the client is a bot, Radar can differentiate between different types of bots such as AI agents or search engine crawlers, giving developers the ability to control which kinds of bots are restricted.
Block or challenge sign-in attempts that are part of an attempt to break into accounts with stolen credentials.
These are attacks where a bad actor is trying many sign-ins over a short period of time. Radar leverages the device fingerprint to identify and isolate bad actors from legitimate traffic, ensuring that your users can use your app even when it’s under attack.
Block or challenge sign-in attempts that occur from different geolocations in short succession.
By tracking device geolocation, Radar can detect when subsequent authentication requests are spread around the globe. Radar will detect if these attempts happen over a short period where it’s not possible for the person to physically travel that distance
Get notified when an account that has been dormant without use becomes active
In contexts such as financial services, a dormant account becoming active might be an indication that the account has been taken over from the user and is being used for fraud. For these kinds of apps, Radar can notify the user and administrator if an account that hasn’t been used in a while has a sign-in attempt. Accounts are considered stale if there have been no successful sign-in in the past 30 days.
Get notified when a device that has never been used before signs in to an account
Using the device fingerprint, Radar checks if the device being used has been part of a successful sign-in before. If it hasn’t, both the user and an administrator can be notified by email.
Specific user identifiers can be configured to always allow or deny an authentication attempt. Examples of using a custom restrictions:
Note: the allow list takes preference – if an user matches an identifier that is in the allow list, they will bypass all other Radar rules.