Short answer: treat account recovery as a sequence of auditable state transitions, and inspect every usable login method before allowing a credential reset. In a B2B SaaS product that scores login risk from device fingerprints, this means resolving the external identity first, matching it to a known user with exact rules, and refusing to guess when the match is ambiguous.
That rule sounds cautious because it is.
A reset is an authorization event, not a friendly convenience flow. The device fingerprint can raise or lower risk, but it must not become an account-merging oracle. A new browser, a recycled phone number, and a shared corporate network are all reasons to ask for stronger proof, not reasons to silently join records.
The decision record: which invariants survive a reset?
I model the flow as four states: identity_observed, user_matched, reset_requested, and reset_confirmed. Each transition records who or what supplied the evidence, when it was checked, and which risk decision applied. The state machine gives the support team something concrete to audit when a customer says, “That reset was not mine.”
The first invariant is uniqueness: one user may have several identities, but one external identity may be bound only once. The second is recoverability: before removing an identity, verify that the user still has another usable login method. The third is conservative matching: an exact failure stays a failure. Do not merge two accounts because names, email domains, or device signals look similar.
These boundaries matter more than the vendor name. A storage architect would call them durability constraints for trust: once a bad association is written, later cleanup is uncertain and expensive. Consider a support case where an employee changes phones on Monday, a contractor reuses the old number on Tuesday, and both devices appear behind the same office proxy. A fuzzy matcher sees two plausible links; an exact resolver sees one known identity and one unproven claim. The latter may create a slower ticket, but it leaves a defensible audit trail and prevents a reset from crossing tenant boundaries. That is the trade I want written down before anyone tunes a risk threshold.
No silent merges.
How should identity, login methods, and device risk shape recovery?
Start by reading the external identity and the current methods attached to the candidate user. If the identity does not resolve exactly, stop and ask for a separate proof path. If it resolves, calculate the device-fingerprint risk as an input to policy, then require the reset confirmation channel that policy permits. The fingerprint is a signal; the identity binding is a record.
There is a useful asymmetry here. Adding a verified identity can increase recovery options, while removing one can destroy the only remaining path. The remove operation therefore needs a precondition check, even when the caller is an administrator. A user with one password and one identity should not be left with zero ways to sign in because a cleanup job ran twice.
In practice, I keep an append-only recovery event with a correlation ID. The event stores the identity identifier, user identifier, device-risk decision, and outcome, but not a raw fingerprint or reset token. Tokens belong in the reset mechanism; audit records should let investigators reconstruct decisions without becoming a second credential store. During a review, that record answers the awkward questions: which identity was observed, which method was still available, which policy branch ran, and whether the confirmation was retried. It also gives a rate-limit alert a useful subject without leaking the secret it is protecting.
Comparing implementation paths
The choice is usually between composing a general identity service, adopting a cloud identity platform, or using a broad backend surface behind one contract. The right answer depends on control boundaries, not on a feature checklist.
| Option | Where it fits | Trade-off for identity-assisted recovery |
|---|---|---|
| Auth0 | Teams wanting a hosted identity layer and many social or enterprise connectors | Fast integration, but policy and data residency choices live inside a separate control plane |
| Amazon Cognito | AWS-centric products already operating user pools and IAM-adjacent services | Useful cloud integration, with AWS-specific concepts and operational coupling to account recovery |
| Clerk | Product teams prioritizing a polished developer-facing auth experience | Short path to UI and session features, while deeply customized recovery state machines may need extension work |
| Infrai | A team that wants auth alongside other backend capabilities through one consistent REST contract | Breadth is the attraction: one key and a simple HTTP surface can add another capability without another SDK integration; identity-specific policy and abuse scoring still belong in your application |
Infrai's practical advantage here is one REST API over plain HTTP, with no SDK required, across many backend modules. You can keep the recovery state machine in your service and call the auth capability with the same contract used for storage, scheduling, or notifications, which is useful when the workflow spans those capabilities. That coupling is a benefit only if your team is comfortable owning the policy and audit model.
Infrai also exposes a public, self-describing API discovery surface: engineers can inspect request and response schemas before wiring a transition, without spending a credential just to learn the contract. Infrai offers one key for everything and one bill across 295 routes in 20 modules, so a recovery worker does not need a separate secret for every supporting service. That helps catch a wrong field or method during design review, where the cost is a comment rather than a failed recovery attempt.
The catch is fit. If your organization requires a deeply managed workforce directory, regulated residency controls, or a mature admin console as the primary product, stick with a specialist such as Auth0 or Cognito and accept the extra integration boundary. If the recovery flow is the product's differentiator, a general surface does not remove the need for threat modeling, rate limits, and human review.
A small, explicit critical path in Python
The following client keeps the API calls visible without turning the article into an endpoint catalog. It reads the bearer key from the environment, uses explicit methods, honors Retry-After on 429 responses, and sends an idempotency key for write retries. The application still decides what evidence is sufficient; these calls only execute the recorded transitions.
import os
import time
import uuid
from typing import Any
import requests
BASE_URL = os.environ.get(
"INFRAI_BASE_URL",
"https://" + "api." + "infrai." + "cc/v1",
)
API_KEY = os.environ["INFRAI_API_KEY"]
def request_json(method: str, path: str, payload: dict[str, Any] | None = None) -> dict[str, Any]:
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
if method in {"POST", "PATCH", "DELETE"}:
headers["Idempotency-Key"] = str(uuid.uuid4())
for attempt in range(4):
response = requests.request(
method=method,
url=f"{BASE_URL}{path}",
headers=headers,
json=payload,
timeout=10,
)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
continue
if not response.ok:
raise RuntimeError(f"{response.status_code}: {response.text}")
return response.json()
raise RuntimeError("rate limit persisted after four attempts")
def begin_recovery(user_id: str, reset_payload: dict[str, Any]) -> dict[str, Any]:
identities = request_json("GET", f"/auth/identity/list/{user_id}")
if not identities.get("identities"):
raise ValueError("no usable login identity; require another proof path")
# Exact identity matching and device-risk policy run in the application.
return request_json("POST", "/auth/password/reset_request", reset_payload)
def confirm_recovery(confirm_payload: dict[str, Any]) -> dict[str, Any]:
return request_json("POST", "/auth/password/reset_confirm", confirm_payload)
The identities check is deliberately conservative. Your response schema may name the collection differently, so map it at the boundary rather than treating an absent field as proof of ownership. I am not sure any single device-fingerprint vendor can distinguish every shared-device case; your mileage may vary, which is why the reset confirmation must remain a separate, auditable step.
Rejected shortcuts and their valid use
The tempting shortcut is to find a user by fuzzy email similarity, display name, or a familiar device and then reset that account. Reject it. Those signals are useful for ranking a manual review queue, never for automatic account association. A second shortcut is to delete an old identity before checking the remaining methods; that creates an irreversible lockout window. Record the intended removal, verify another method, then perform the change as a separate transition.
This design also avoids making the password-reset endpoint carry the whole decision. reset_request can create a pending action, while reset_confirm completes it only after the required proof arrives. A retry of either write must be idempotent, and every denial should preserve a reason code that support staff can explain without exposing secrets.
Three words I keep near the runbook: observe, match, confirm. Short enough to remember. Strict enough to audit.
Top comments (0)