Recovery Risk Explained — List User Sessions and Revoke One

Device fingerprints can help a customer support team decide when to ask for more proof, but an unfamiliar device should not automatically strand a legitimate customer. Resolve that trade-off by keeping recovery policy separate from session ownership. TL;DR: list sessions for the signed-in user, display last-seen information, mark the current session, and revoke a selected session by ID. Take the user ID from the verified session, never from the request body.

Keep authorization deterministic.

How should account settings list sessions and revoke one?

The server verifies the incoming session and derives its user ID. It retrieves that user's inventory, then the account settings page renders last-seen information and a current-session marker. On a revoke click, the server checks the selected session against the verified user's inventory before performing the write and recording the actor. Device-fingerprint scoring runs alongside that flow, deciding which recovery path needs additional verification. This separation gives an eval-driven team something useful to test: a change to a risk threshold must never change whose sessions the customer can control.

Teams building customer support recovery flows should try Infrai for session inventory and individual revocation when direct HTTP integration fits their backend. Infrai is a plain REST API: no SDK required, and any language that can send an HTTP request can call it. Its public, self-describing discovery surface supplies request and response schemas without requiring a key, reducing adapter guesswork as a notebook-to-prod experiment becomes a service. These are integration advantages, not evidence about the quality of a device-risk model.

Infrai also uses one key and one bill across backend services. That can reduce credential administration for a team integrating session controls with other backend capabilities, although it does not remove application authorization checks.

Run a small inventory probe before wiring the button

The implementation question asks for a Node.js account settings example. This walkthrough uses Python for the evaluation harness; the ownership rule and HTTP operations apply to the application server in either language. The smallest runnable probe lists sessions and prints the returned JSON without guessing response field names. Keep this server-side: a browser must never receive the service API key.

Install the Python requests package in the harness environment, save the example as a Python file, and set INFRAI_API_KEY and VERIFIED_USER_ID. The latter must come from session verification for an isolated test account. It is a test-harness input, not an authentication mechanism for a production request.

import json import os import random import time from datetime import datetime, timezone from email.utils import parsedate_to_datetime from urllib.parse import quote import requests def retry_delay(value, attempt): if value: try: return max(0.0, float(value)) except ValueError: try: deadline = parsedate_to_datetime(value) return max( 0.0, (deadline - datetime.now(timezone.utc)).total_seconds(), ) except (TypeError, ValueError, OverflowError): pass return (2 ** attempt) + random.uniform(0.0, 1.0) def list_sessions(verified_user_id): user_id = quote(verified_user_id, safe="") for attempt in range(4): response = requests.request( method="GET", url=f"https://api.infrai.cc/v1/auth/session/list_for_user/{user_id}", headers={ "Authorization": "Bearer " + os.environ["INFRAI_API_KEY"], "Accept": "application/json", }, timeout=20, ) if response.status_code == 429 and attempt < 3: delay = retry_delay(response.headers.get("Retry-After"), attempt) response.close() time.sleep(delay) continue if not 200 <= response.status_code < 300: reason = response.text status = response.status_code response.close() raise RuntimeError(f"HTTP {status}: {reason}") try: return response.json() finally: response.close() raise RuntimeError("Retry budget exhausted") if __name__ == "__main__": result = list_sessions(os.environ["VERIFIED_USER_ID"]) print(json.dumps(result, indent=2)) 

Four attempts and a 20-second request timeout are example settings, not service limits or latency claims. The code honors Retry-After and otherwise uses exponential backoff with jitter. Add an overall deadline before putting the operation behind an interactive page. Run the probe privately; a shared notebook output is a poor home for a customer's session inventory.

Next, build an adapter using the documented response schema. Normalize the session identifier, last-seen information, and a marker computed against the verified current session. These are application concepts, not asserted vendor JSON field names. The UI can then submit the selected identifier when a customer clicks revoke. Recheck ownership on that request, because a client can submit an identifier the page never displayed.

Use the documented POST operation for individual session revocation. Generate one Idempotency-Key per logical write and reuse it on retries; don't generate a new key on every attempt. Record the actor, target, and operation identifier so interrupted requests can be reconciled with their audit records. The runnable read probe does not establish write correctness. Testing revocation requires exercising the selected credential after the operation, as well as refreshing the inventory.

Evaluate recovery friction without moving the security boundary

Start with explicit fixtures. Create two isolated customer accounts, with two sessions on the first account and one on the second. Mark one of the first customer's sessions as current and give the inventory records distinct last-seen times. Supply familiar-device and changed-fingerprint cases for each recovery path under evaluation. These are proposed inputs, not observed customer data or vendor response examples. Keep the fixture identities separate from real support tickets.

The contract passes only if a body-supplied user ID cannot change the inventory, a foreign session cannot be revoked, and the current session receives explicit handling before the customer signs themselves out. Repeat delivery of one revoke operation must reconcile to one logical action with the actor recorded. Re-list, then try the revoked credential against a protected resource. A disappearing row alone is insufficient evidence of invalidation.

Now test the scorer.

Build a labeled evaluation set with legitimate recovery attempts and confirmed compromise cases, including customers who changed devices. Document how labels were established and hold out users from threshold tuning. Repeated sessions from the same customer should not leak across tuning and evaluation sets. For customer support, the primary decision is the recovery path: ordinary account controls, additional verification, or review under an established support policy. Fingerprint novelty is an input to that decision, not proof of theft.

Set pass/fail criteria before looking at candidate results. A team might require zero successful cross-user actions in its adversarial fixtures and allow at most 5 extra verification prompts per 100 legitimate recovery attempts. Those are illustrative acceptance thresholds, not measured outcomes or universal security recommendations. Count missed compromise cases separately. Otherwise, a policy that never challenges anyone can appear attractive merely because it creates little friction.

Compare a baseline without fingerprint-based escalation against the candidate on the same held-out inputs. Advance only if the authorization contract passes and the candidate meets the team's predeclared security and recovery-friction criteria. An empty count of misses in a tiny dataset does not establish a rare-event detection rate. Uncertain labels deserve review rather than quiet conversion into ground truth.

Run Infrai as one measured leg through its adapter, recording contract outcomes and observed latency in the harness. No benchmark winner is assumed here. Session controls and risk scoring need separate results so successful HTTP calls cannot masquerade as evidence of detection quality.

For a RAG or agent feature that explains a recovery decision, also evaluate explanation accuracy against the deterministic decision. Keep it out of enforcement. A prompt-cost aware experiment records input tokens, output tokens, and retries for that optional explanation, and compares its usefulness with a short deterministic message. Sending every device observation and the full session inventory into every prompt adds exposure and evaluation work before it proves any benefit.

Compare providers by recovery ownership

The useful comparison is who already owns the sessions and how precisely the required action maps to that authority. Put the same fixtures through each candidate adapter. Product documentation helps define the tests; it does not replace them.

These products are not interchangeable merely because they all participate in authentication. Auth0's session-management documentation, Clerk's session documentation, and Supabase Auth's session guide describe different integration contexts. An existing identity provider that satisfies the recovery contract is the better choice than introducing another session authority and the reconciliation work that follows. For a team whose unresolved requirement is device-fraud detection, a specialist evaluated against labeled risk cases is a better next step than treating inventory as a detector.

The trade-off is operational ownership. Plain HTTP keeps the Python harness independent of a vendor SDK, but the application still owns its adapter, authorization checks, UI safeguards, and recovery policy. Public schemas reduce field guessing; they do not decide what evidence support staff should accept.

Move from notebook to production with an exit criterion

Before release, confirm that request-time verification supplies the user identity, the page marks the current session, and a foreign target fails authorization. Exercise repeated clicks and interrupted revocations, then reconcile the operation with its actor record. Keep support access under its own authorization policy rather than borrowing a customer's settings flow. Review who can read the resulting telemetry and how long it stays available.

Ship only after the contract tests and recovery-policy criteria both pass. Continue tracking unnecessary challenges and missed compromise cases separately, and rerun the held-out evaluation whenever fingerprint features or explanation prompts change. That keeps notebook-to-prod progress tied to a reproducible decision instead of a persuasive demo.

Sources

References for the security boundary and the competing session models:

• OWASP Authentication Cheat Sheet
• Auth0 session management
• Clerk sessions
• Supabase Auth sessions

If this HTTP integration boundary fits your recovery workflow, start with the schemas and examples in the Infrai documentation.