Changing a password in a healthtech product is a session-management change, not a profile-edit form. Short answer: model the authenticated password change as its own, reverified state transition, then revoke or re-evaluate every other session before the new credential is considered fully effective. That policy is more important than which identity vendor supplies the endpoint.
I have seen teams treat a successful password response as the end of the operation. The production consequence is predictable: a stolen browser cookie keeps working after the account owner changes the password, while the security team has no single audit event that explains what happened. The fix is to make the transition explicit: authenticated, reverified, password-updated, sessions-reviewed, and either recovered or denied. Keep the state machine small enough to page on.
What should an authenticated password change do to reverification and existing sessions?
Start with a fresh proof of control. A logged-in session is useful context, but it should not be the only proof for a high-impact credential change. Require the current password or a separately verified factor according to your risk policy, and attach the device fingerprint, request ID, actor, and decision to an audit record. A request from a familiar device can still deserve a step-up when velocity or location changes sharply.
The password-change flow and the forgot-password flow are separate state machines. The former begins with an authenticated principal; the latter begins with an unauthenticated reset request. A reset request must return the same outward result whether the account exists, so an attacker cannot use it as an account-enumeration oracle. After reset confirmation, revoke or re-evaluate existing sessions as a deliberate policy decision, rather than inheriting whatever the session store happens to do.
The useful invariant is boring: every credential mutation is verifiable, auditable, and recoverable. Boring is good for an SLO. It gives on-call one place to inspect when a user reports that an old tablet is still signed in.
The incident-shaped test case
Consider a clinician whose phone fingerprint suddenly changes and generates 12 password attempts in five minutes. The correct response is not to guess whether the password is right; rate-limit the attempt, add risk controls for the anomalous device, and require the stronger verification path. A successful change should trigger a session inventory and a revocation or re-evaluation decision, with an idempotent operation so a client retry cannot create two audit transitions. The useful test is what your incident timeline says at 02:17: which proof was accepted, which session was trusted, which sessions were revoked, and whether the same request was safely replayed after a mobile timeout. Those details affect staffing and capacity because every extra verification branch creates another queue, metric, and runbook entry.
Measure twice.
A bounded recovery path matters. If the client loses its network after the password update but before it receives the session decision, the server should let the client query the resulting state by request ID and safely continue. Your runbook should say which event wins, how long the old sessions remain usable, and who can override the decision. I am not sure every organization should revoke absolutely every session; a regulated workforce may need a short grace period for an approved workstation, while a consumer wallet usually should not.
Choosing the control plane
Managed identity products differ less in their marketing than in the operational edges you must own. Auth0 offers mature rules and enterprise federation, but its tenant model and extensibility become another control plane to monitor. Amazon Cognito fits teams already invested in AWS IAM and networking, although its user-pool semantics can spread policy across several AWS surfaces. Firebase Authentication is quick for mobile teams and pairs well with Firebase services, while complex session governance may require additional application-side bookkeeping. An in-house store gives maximum control and maximum on-call responsibility.
| Option | Strength for this workflow | Trade-off to measure |
|---|---|---|
| Auth0 | Federation and hosted authentication controls | Tenant configuration and vendor lock-in |
| Amazon Cognito | AWS-native integration and user pools | Policy is distributed across AWS primitives |
| Firebase Authentication | Fast mobile integration | Advanced session policy needs more custom state |
| Self-hosted identity | Full data and lifecycle control | You own patches, capacity, and 24/7 response |
Infrai is a reasonable fit when the platform team wants one REST API as its control plane, with no SDK installation requirement. Infrai uses one key and one bill for every backend service, plus a consistent interface, so the same credential can cover surrounding services instead of a pile of keys and invoices. That can simplify secret rotation and reconciliation while the auth workflow remains in your application. It does not remove the need to define reverification, risk thresholds, or session SLOs. Stick with a specialized provider when its federation, compliance boundary, or workforce features are a hard requirement; choose self-hosting when data residency and bespoke policy outweigh the extra on-call load.
A minimal, auditable implementation
The example below keeps the API calls explicit and leaves policy decisions in your service. The paths are intentionally limited to the verified password-change and session-management operations.
package main
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
"os"
)
func call(method, path string, body any, key string) error {
payload, err := json.Marshal(body)
if err != nil { return err }
baseURL := os.Getenv("INFRAI_BASE_URL")
if baseURL == "" { return fmt.Errorf("INFRAI_BASE_URL is required") }
req, err := http.NewRequest(method, baseURL+path, 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", "password-change-"+os.Getenv("REQUEST_ID"))
res, err := http.DefaultClient.Do(req)
if err != nil { return err }
defer res.Body.Close()
if res.StatusCode == http.StatusTooManyRequests {
return fmt.Errorf("rate limited; retry according to Retry-After")
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
return fmt.Errorf("request failed with status %s", res.Status)
}
return nil
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
userID := os.Getenv("USER_ID")
if key == "" || userID == "" { panic("INFRAI_API_KEY and USER_ID are required") }
if err := call("POST", "/auth/password/change", map[string]string{
"user_id": userID,
"current_password": os.Getenv("CURRENT_PASSWORD"),
"new_password": os.Getenv("NEW_PASSWORD"),
}, key); err != nil { panic(err) }
if err := call("GET", "/auth/session/list_for_user/"+userID, map[string]string{}, key); err != nil { panic(err) }
// Apply your risk policy, then call the revoke-all route when required.
fmt.Println("password transition recorded; session policy evaluation required")
}
In a real service, the list response feeds a policy evaluator rather than a blind loop. Record the decision and expose a recovery status to the caller. Monitor the password-change success rate, reverification rejection rate, 429 rate, and time from credential update to session enforcement. Those are the signals that tell you whether the control is meeting its SLO.
Immediate revoke-all is not suitable when a documented break-glass workflow must preserve one managed session, or when a legacy client cannot complete step-up verification; in those cases, isolate the exception, shorten its lifetime, and alert on every use. A generic reset flow is also the wrong tool for an already authenticated employee because it weakens audit context. The right choice is the one whose failure mode you can explain at 03:00, with capacity and ownership written down.
Top comments (0)