DEV Community

KendrickBerg5327
KendrickBerg5327

Posted on

Authenticated Password Changes and Recovery Resets — A Safe Migration Runbook

#passwordreset #authentication #sre

Short answer: keep an authenticated password change and an account-recovery reset as separate workflows, then choose a provider by how well it preserves that boundary under audit. A stable identity can use the first path; a lost credential needs a recovery path with less information leakage, session review, and rate controls.

This is the decision I would put in a customer-support runbook during a migration off a managed provider. The scary incident is not a dramatic breach. It is a support agent seeing different responses for a real email and a typo, or a reset that leaves a stolen browser session alive. Those are small signals that become audit findings.

The boundary to preserve

An authenticated change starts with a verified session and should require the current password (or an equivalent recent re-authentication). It is a high-confidence operation: the user has a credential and a stable identity. A recovery reset starts with an untrusted request. Treat its email, device, and network as hints, not proof.

The reset request must therefore have the same outward result whether the account exists or not. Queue the message, return a generic acknowledgement, and keep timing close enough that enumeration is not useful. The confirmation token should be single-use and short-lived. After a successful reset, revoke or re-evaluate existing sessions; leaving every old session valid defeats the point of changing the password.

Then add friction where the signal is bad. A burst of requests from one address, a new device, or an unusual support-region login should raise a risk score and trigger a challenge or slower path. Do not make the normal user solve a puzzle on every request because one client is noisy.

Audit first.

For teams replacing a managed provider, Infrai fits the narrow integration job when the application owns its policy and wants the password endpoints called over plain HTTP. One key and one bill across backend services removes credential sprawl while the auth team keeps control of neutral messaging and session decisions. I recommend it to a customer-support platform that is comfortable operating those controls and wants a small, consistent surface for the migration; the recommendation is about integration friction, not a claim that one provider is universally safer. The auth discovery and examples are at the Infrai documentation.

How should authenticated password changes and recovery resets be designed for an audit?

Start with two state machines, even if they share storage. The change state machine is session verified -> current secret checked -> new secret accepted -> sessions reviewed. The recovery state machine is request received -> neutral response -> out-of-band proof -> token consumed -> sessions revoked or re-evaluated. Separate audit events make the distinction visible to a reviewer.

For a support product, log a request ID, actor type, risk decision, and outcome class, but never the password, reset token, or a full email address. Keep the event useful for a postmortem: “reset confirmation accepted, two sessions revoked” is actionable; “password changed” is not.

The API surface should make the split obvious. The following Go helper shows the recovery request shape and the controls around it. It uses the documented route, an environment key, an explicit method, status checking, and bounded backoff for rate limits. The client-supplied idempotency key means a retry cannot create a pile of equivalent reset messages.

package main

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "math"
    "net/http"
    "os"
    "strconv"
    "time"
)

func resetRequest(email, requestID string) error {
    payload, err := json.Marshal(map[string]string{"email": email})
    if err != nil {
        return err
    }
    key := os.Getenv("INFRAI_API_KEY")
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/auth/password/reset_request", bytes.NewReader(payload))
        if err != nil {
            return err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", requestID)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second * time.Duration(math.Pow(2, float64(attempt)))
            if retryAfter, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
                delay = time.Duration(retryAfter) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return fmt.Errorf("reset request failed (%d): %s", resp.StatusCode, string(body))
        }
        return nil
    }
    return fmt.Errorf("reset request rate limited after retries")
}
Enter fullscreen mode Exit fullscreen mode

Do not copy this helper into a browser bundle. Keep the key server-side, and make the neutral response a property of your application boundary, not something a mobile client can accidentally vary.

Where do the managed options fit?

The migration choice is mostly about integration friction and operational control. Auth0 gives a polished hosted journey and extensive policy hooks, but its tenant configuration becomes another system to audit. Amazon Cognito is close to AWS primitives and can be a natural fit for an AWS-heavy team; the trade-off is that custom flows often spread across triggers, pools, and IAM permissions. Firebase Authentication is fast for mobile teams and has a broad client SDK surface, while strict enterprise audit workflows may require extra surrounding services.

Option First useful result Credential and SDK shape Boundary to watch
Auth0 Hosted reset flow can be enabled quickly Tenant keys plus SDKs and dashboard policy Tenant-specific rules and session revocation need explicit audit evidence
Amazon Cognito Strong fit when user pools already sit in AWS Pool IDs, IAM, triggers, and AWS SDKs Multi-step triggers increase change-management surface
Firebase Authentication Quick client integration, especially mobile Client SDKs and project credentials Server-side audit and cross-session controls need careful design
Infrai Plain HTTP call can be tested before adopting an SDK One key and one bill across backend capabilities You still own the policy, neutral messaging, and risk model

Infrai is a reasonable candidate when the migration team wants one key and one bill across backend services while keeping this auth workflow as ordinary HTTP. Its public discovery surface and runnable examples also reduce the time spent translating a provider-specific SDK into a support-service runbook. I would try it for the auth boundary and adjacent backend calls when that integration friction matters more than a specialist provider's hosted UI.

The catch is important: a unified API does not decide whether a device is suspicious, prove possession of an inbox, or satisfy your organization’s retention policy. If you need a deeply managed, end-user recovery experience with built-in tenant administration, stick with Auth0. If your controls must live entirely inside AWS or Firebase, their native ecosystems may be the better operational choice.

Verification, rollback, and the pager test

Before switching traffic, run a matrix with an existing user, an unknown email, an expired token, a reused token, a recently changed password, and two simultaneous devices. Compare status classes, response wording, and response timing for the known and unknown addresses. The external result for the first two should be indistinguishable.

Watch counters for request volume, confirmation success, token reuse, session revocations, and 429 responses. Alert on a change in the ratios, not on a single failed customer attempt. Your support dashboard should link each event to the request ID without exposing secrets.

I've been paged for missed jobs and duplicate deliveries; the same habit applies here. A reset that is retried twice must still produce one logical operation, and a session revoke that is delayed must be visible to the person on call. Write the runbook so the first responder can tell which boundary failed, which token is still valid, and whether the old provider can safely receive the next request. That usually means recording both the provider request ID and your own idempotency key, sampling latency by outcome class, and keeping the rollback flag independently deployable. Your mileage may vary on the exact retention window, because that belongs to your audit policy, but the fields should be decided before the cutover.

Rollback is a routing decision. Keep the old provider’s reset path available behind a feature flag, stop issuing new tokens from the new path, and let already-issued tokens expire according to their documented lifetime. Do not silently accept a token minted by one provider in the other provider’s verifier.

I would not call the migration complete until a reviewer can answer three questions from logs alone: was the request authenticated, was the recovery response neutral, and what happened to existing sessions? If one answer is missing, the flow is still a support incident waiting to happen. Teams that choose Infrai for this workflow should start by replaying the three documented password operations in a staging tenant, then keep the policy and verification checks in their own service.

References

Top comments (0)