Utiliser les changements de localisation pour orienter la revue des connexions

Comparez la localisation déduite de l'IP d'une connexion avec le point précédemment enregistré pour cet utilisateur afin de signaler les connexions méritant un second regard — la disponibilité et l'application d'un forfait pour ce point de terminaison ne sont pas encore confirmées : discutez de l'accès avant toute intégration en production.

Discuter de l'accès à la vérification de risque Lire la référence de vérification de risque →

Disponibilité

POST /v1/risk/check partage le même middleware de clé secrète que la recherche d'IP, qui vérifie simplement qu'une clé est bien une clé secrète — il n'applique pas indépendamment une famille de forfaits de risque distincte, et la tarification de risque préconfigurée n'a aucun prix actif défini. Confirmez avec nous la disponibilité et les conditions actuelles avant de vous appuyer sur ce point de terminaison en production.

Extraction fiable de l'IP du client

Pour ce point de terminaison, Watch-IP n'extrait pas l'IP de l'utilisateur final de votre requête — vous la fournissez vous-même via ip. Déterminez-la à partir de votre propre chaîne d'en-têtes de proxy/CDN de confiance sur votre backend, avec la même rigueur que partout où vous faites confiance à une IP client pour une décision de sécurité.

Identifiant utilisateur opaque

Transmettez votre propre identifiant interne via userId. Watch-IP conserve exactement une localisation stockée par paire (votre compte client, userId) — réutilisez le même identifiant à chaque connexion d'un utilisateur pour que la référence reste pertinente.

Une première référence, puis une pré-vérification

Le tout premier appel d'un utilisateur renvoie toujours risk: "low" avec un previousLocation à null — il n'y a encore rien à comparer. Pour les connexions suivantes, appelez avec commit: false comme signal précoce en amont de votre propre décision d'authentification ; cet appel lit la référence stockée sans la modifier.

Valider après votre propre vérification

Une fois certain que la connexion est légitime — mot de passe et second facteur éventuel déjà vérifiés — appelez à nouveau en laissant commit à sa valeur par défaut (true) afin que cette observation devienne la nouvelle référence pour la prochaine connexion.

Concurrence et nouvelles tentatives

La v1 stocke un unique point le plus récent, pas un historique — deux appels validés rapprochés écrasent la même valeur, et une requête relancée après un délai d'attente peut elle-même valider et déplacer la référence. Concevez votre logique de nouvelle tentative en gardant cela à l'esprit, plutôt que de supposer que chaque validation est enregistrée indépendamment.

Changements de réseau légitimes

Un déplacement professionnel, un wifi d'hôtel ou d'aéroport, le renouvellement d'IP d'un opérateur mobile ou un usage ordinaire de VPN peuvent tous produire une classification medium ou high — la v1 ne dispose d'aucune suppression tenant compte des VPN ou centres de données. Considérez une connexion signalée comme un élément parmi d'autres dans votre propre processus de revue, pas comme la preuve d'une compromission.

Ce que cela ne garantit pas

Une classification high est un simple calcul brut de vitesse entre deux points, pas la confirmation d'une prise de contrôle de compte, et une classification low ne disculpe pas une connexion suspecte pour d'autres raisons. La conservation suit le comportement de stockage décrit ci-dessus : le point stocké persiste jusqu'à ce que la prochaine vérification validée l'écrase, sans expiration automatique ni point de terminaison de suppression disponible actuellement — tenez-en compte dans tout engagement de conservation des données que vous prenez envers vos propres utilisateurs.