位置の変化をログイン審査に活用する
ログイン時のIP由来の位置情報を、そのユーザーの直前の保存済み地点と比較し、再確認すべきログインにフラグを立てます—このエンドポイントの利用可否とプランの適用はまだ確認されていないため、本番環境で統合する前にアクセスについてご相談ください。
利用可否
POST /v1/risk/checkは、キーがシークレットキーであることを確認するIPルックアップと同じミドルウェアを共有しています—独立したリスクプランファミリーを強制するものではなく、シードされたリスク料金には有効な価格設定がありません。本番環境でこのエンドポイントに依存する前に、現在の利用可否と条件についてお問い合わせください。
信頼できるクライアントIPの抽出
Watch-IPは、このエンドポイントについてお客様のリクエストからエンドユーザーのIPを抽出しません—ipとして指定していただく必要があります。バックエンドの信頼できるプロキシ/CDNヘッダーチェーンからそれを解決してください。セキュリティ上の判断でクライアントIPを信頼する場合と同じ注意が必要です。
不透明なユーザーID
userIdには自社の内部識別子を渡してください。Watch-IPは(お客様のアカウント、userId)のペアごとに、保存された位置情報を1件のみ保持します—ユーザーのログインごとに同じ識別子を再利用することで、ベースラインの意味を保てます。
最初のベースラインとその後のプリチェック
ユーザーの最初の呼び出しは常にrisk: "low"とnullのpreviousLocationを返します—まだ比較対象がないためです。その後のログインでは、自社の認証判断の前段のシグナルとしてcommit: falseで呼び出してください。この呼び出しは保存済みのベースラインを読み取るだけで、更新しません。
自社の検証後にコミットする
ログインが正当であると確信できたら(パスワードと第2要素の検証が完了した後)、commitをデフォルトの値(true)のままで再度呼び出してください。これにより、この観測結果が次回のログインの新しいベースラインになります。
並行処理とリトライ
v1は履歴ではなく、最新の1地点のみを保存します—短時間に連続してコミットされた2つの呼び出しは同じ値を上書きし、タイムアウト後にリトライされたリクエストがそれ自体でコミットされ、ベースラインをずらしてしまう可能性があります。各コミットが個別に記録されると想定せず、これを踏まえてリトライロジックを設計してください。
正当なネットワークの変化
出張、ホテルや空港のWi-Fi、モバイルキャリアのIPの入れ替わり、通常のVPN利用は、いずれもmediumまたはhighの分類を生み出す可能性があります—v1にはVPN/データセンターを考慮した抑制機能はありません。フラグが立てられたログインは、侵害の証明ではなく、自社の審査プロセスへの1つの入力として扱ってください。
これによって保証されないこと
high分類は2点間の生の速度計算にすぎず、アカウント乗っ取りの確認ではありません。また、low分類は、他の理由で疑わしいログインを問題なしと判定するものではありません。保持については上記の保存動作に従います:保存された地点は、次にコミットされたチェックによって上書きされるまで保持され、自動的な期限切れはなく、現在削除用のエンドポイントもありません—自社の利用者に対するデータ保持に関する取り組みにこれを反映させてください。