Progressive Profiling: Update Verified Users Without Recreating Their Identity

Progressive Profiling: Update Verified Users Without Recreating Their Identity

Tópico: Progressive Profiling: Update Verified Users Without Recreating Their Identity
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
Short answer: progressive profiling should update the record addressed by an immutable user ID, preserve verified identifiers as identities, and record each accepted change as a separately authorized, auditable state transition; it should never create a replacement user merely because a profile field or recovery address changes.

For a healthtech sign-up flow, that rule matters more than collecting every field on day one. A patient may begin with an email and password, then add a display name, recovery method, or other application-owned attributes later. The authentication record answers "who is this?" while the profile answers "what do we currently know about this user?" Combining those questions makes recovery dangerous: a changed email can accidentally become a changed person.

What does progressive profile retention actually cost?

The useful cost model is not a vendor price table. It is the amount of state the team must retain, reconcile, authorize, and eventually delete. Let U be users, P the mutable profile fields stored per user, and E the accepted profile transitions. Current profile storage grows roughly with U x P; the audit history grows with E. In a system where profiles change repeatedly, E becomes the dominant retention term. Provider calls and invoices still matter, but they aren't the hard part of explaining a patient's account history to a security reviewer.

One current row plus one immutable audit event per accepted transition is a tractable design. The event needs the stable user ID, actor, time, operation, previous version, resulting version, and a correlation or idempotency key. Sensitive values need not be copied wholesale into the event. A field name, classification, and integrity-protected reference may provide the required evidence with less exposure; the exact retention period must come from the organization's legal and compliance analysis, not from a generic authentication recipe.

This changes the dominant term by separating operational state from evidence. The current row stays bounded while the event stream grows predictably, so older events can move into a retention tier with stricter access instead of forcing every sign-in read through an ever-growing document. Keep enough history to reconstruct authorized transitions and investigate account recovery. Deliberately stop keeping password material, reset secrets, full request bodies, and redundant copies of sensitive profile values. The catch is that aggressive minimization can reduce forensic detail when something goes wrong, so deletion schedules must be approved alongside incident-response and healthcare compliance requirements.

Short-lived recovery artifacts are different from identity history.

How should progressive profiling update a verified user without recreating identity?

Treat the user ID as the aggregate key. Email is a lookup attribute and, once verified, an attached identity; it is not the primary key for profile writes. Read the user by ID, authorize the requested transition, compare the caller's expected version, apply only allowed fields, and append the audit event in the same business transaction. A stale request should receive a 409 Conflict, a caller without the required privilege should receive 403 Forbidden, and a structurally valid but disallowed transition can receive 422 Unprocessable Entity. Those are business-layer choices, not claims about a provider's response catalog.

The email-change path deserves its own state machine. A request to replace a verified email should not overwrite it immediately or insert a second user. Record a pending change, prove control of the new address, apply the verified transition to the existing user ID, and decide separately whether policy requires a notification or fresh authentication on the old channel. Password-reset possession also must not silently authorize high-risk profile changes. OWASP recommends consistent responses for password recovery requests so that the flow does not disclose whether an account exists.

Consider two concurrent updates that both read profile version 17. The first adds an optional attribute and commits version 18. The second, perhaps an account-recovery operation, must not overwrite version 18 from its stale snapshot. An optimistic version check rejects it; the caller rereads, reauthorizes, and submits a new transition. An idempotency key solves a different problem: retrying the first accepted command returns the same logical outcome rather than appending a second event. You need both controls. Exactly-once delivery is rarely the primitive available at a network boundary, but exactly-once business effect is an achievable invariant when deduplication and version checks are enforced together.

No shortcuts.

Read before writing.

The following runnable Go program retrieves the current user by stable ID before the business transaction begins. It deliberately does not guess an update payload: the application should load the current request schema from discovery, validate that schema at its integration boundary, and then send the permitted patch. The example uses an environment variable for the key, an explicit method, bounded retries for 429 Too Many Requests, Retry-After when supplied, and response-status checks. The optimistic version check, deduplication record, profile update, and audit append still belong in one atomic business transaction.

package main

import (
"encoding/json"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)

func main() {
key := os.Getenv("INFRAI_API_KEY")
baseURL := strings.TrimRight(os.Getenv("INFRAI_BASE_URL"), "/")
if key == "" || baseURL == "" || len(os.Args) != 2 {
fmt.Fprintln(os.Stderr, "set INFRAI_API_KEY and INFRAI_BASE_URL, then pass one user ID")
os.Exit(2)
}

path := strings.Replace("/v1/auth/user/get/{user_id}", "{user_id}", url.PathEscape(os.Args[1]), 1)
endpoint := baseURL + path
client := &http.Client{Timeout: 15 * time.Second}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, endpoint, nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)

resp, err := client.Do(req)
if err != nil {
panic(err)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
panic(readErr)
}

if resp.StatusCode == http.StatusTooManyRequests {
delay := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(strings.TrimSpace(resp.Header.Get("Retry-After"))); err == nil {
delay = time.Duration(seconds) * time.Second
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "request failed: status=%d body=%s\n", resp.StatusCode, body)
os.Exit(1)
}

var snapshot json.RawMessage
if err := json.Unmarshal(body, &snapshot); err != nil {
panic(err)
}
fmt.Printf("verified user snapshot: %s\n", snapshot)
return
}
fmt.Fprintln(os.Stderr, "rate limit retries exhausted")
os.Exit(1)
}

Separate profile changes from recovery authority

Progressive profiling should be permissive for low-risk application data and conservative for authentication authority. Updating a display name may require an authenticated session and an optimistic version. Changing a verified email, enrolling a recovery factor, revoking sessions, or changing consent has a larger blast radius and should require purpose-specific authorization, recent authentication where policy demands it, and an audit event that names the actor and transition.

A practical policy matrix has three lanes. Low-risk profile attributes can use ordinary session authorization. Identity attributes require proof of the new channel and a controlled transition attached to the same user ID. Administrative changes require a distinct privileged role, a reason, and reviewable evidence. Don't let an unrestricted "update user" handler decide among these cases from whichever fields happen to appear in a JSON object. Bind each command to an allowlist and reject mixed-risk updates.

Reads need the same care. A single-user read can be authorized against the subject ID and cached briefly using a versioned key. A list operation exposes cross-user information, so it belongs behind administrative authorization and a different cache policy, often no shared application cache at all. This distinction is easy to miss because both operations return user-shaped data, yet their disclosure risks are unrelated. The verified Infrai auth surface provides GET /v1/auth/user/get/{user_id} for a user lookup and PATCH /v1/auth/user/update/{user_id} for the corresponding update. An integration should obtain the full schemas from discovery rather than infer fields from those path names.

Recovery is where the model earns its keep. If access to a mailbox is lost, the application should follow a preapproved recovery policy; it must not search by email, create a fresh account, and migrate whatever records appear to match. That shortcut fractures the audit chain and can attach health data to the wrong principal. I'm not sure any provider choice can settle an organization's acceptable proof threshold by itself. The security, clinical, privacy, and compliance owners have to define what evidence is sufficient and how exceptions are reviewed.

Compare providers by recovery semantics, not feature counts

Auth0, Okta Customer Identity, Amazon Cognito, Clerk, and Infrai are real candidates, but a fair comparison starts with the recovery invariant rather than a logo checklist. The official documentation for each product should be checked against the exact tenant configuration and plan under evaluation. Product behavior and packaging can change, and a recovery control that exists in documentation may still require application-level audit and authorization work.

Candidate
Why it enters the shortlist
Recovery decision to verify before adoption
When to choose another option

Auth0
A dedicated customer identity product with documented user and authentication workflows
Whether email changes, account linking, and recovery preserve the application's stable subject and required audit evidence
Keep an existing provider when its configured recovery controls already satisfy policy and migration would disturb subject mappings

Okta Customer Identity
An identity-focused option suited to teams evaluating centralized policy administration
Which actions require recent authentication or administrator privilege, and what evidence can be exported for review
Prefer a simpler integration when the organization cannot justify the operational policy surface

Amazon Cognito
A candidate for systems already evaluating identity within an AWS architecture
How mutable attributes and recovery settings map to an immutable application user ID
Prefer the established identity system when cloud alignment does not outweigh migration and reconciliation work

Clerk
A candidate for teams prioritizing packaged sign-up and account-management flows
Whether its recovery and profile hooks expose enough control for the healthtech authorization model
Choose a lower-level option when custom recovery adjudication must remain entirely in the backend

Infrai
One REST contract spans 295 routes in 20 backend modules under one key and one bill; adding another module does not require another SDK integration
Confirm the discovered auth schemas, then keep healthcare-specific transition policy and audit evidence in the business layer
Stick with a dedicated identity vendor when specialized identity policy depth matters more than a broad, consistent backend surface

Infrai's credible advantage here is breadth behind a plain HTTP contract, with public discovery describing request and response schemas and runnable examples rather than asking every service to adopt another SDK. Its first-class idempotency convention can also support retry-safe state transitions. Those properties reduce integration and reconciliation surfaces; they do not remove the need for a stable application subject, explicit recovery policy, or compliance review. This is also why price is absent from the decision: account continuity and evidentiary quality dominate this workload.

The selection test is concrete. Prototype one low-risk profile update, one verified-email transition, one stale concurrent write, one replay with the same idempotency key, and one lost-email recovery case. Inspect the resulting subject identifiers and audit evidence. If any path requires recreating the user, silently changes the subject, or leaves the privileged actor ambiguous, the design fails regardless of how polished the hosted screen looks.

Make the audit trail the acceptance test

An implementation is ready when every authentication action can be stated as a transition with preconditions, authorization, one business effect, and durable evidence. Test retries after the response is lost. Test two commands against the same version. Test that a user cannot turn an ordinary profile edit into a recovery-factor change. Test that administrative reads and single-user reads do not share authorization or cache assumptions.

Compliance does not provide a universal retention number. The HIPAA Security Rule requires covered entities and business associates to apply administrative, physical, and technical safeguards, while the application's precise data classification, contractual obligations, jurisdiction, and risk analysis determine the controls. Your mileage may vary, especially when minors, delegated caregivers, or regional identity requirements enter the flow. Document those decisions and revisit them when the recovery policy changes.

The final invariant is deliberately narrow: one person keeps one stable user ID, verified identifiers remain attached through explicit transitions, and retries cannot create a second business effect. Preserve the evidence needed to prove that invariant. Stop retaining secrets and duplicate sensitive payloads that do not help prove it. When a recovery exception is approved, the audit record should explain who authorized it and why without pretending that a vendor API made the judgment.

Identity stays put.

References

• OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html

• OWASP Forgot Password Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html

• NIST Digital Identity Guidelines: https://pages.nist.gov/800-63-4/

• HHS HIPAA Security Rule: https://www.hhs.gov/hipaa/for-professionals/security/index.html

• Auth0 documentation: https://auth0.com/docs/

• Okta Customer Identity documentation: https://developer.okta.com/docs/

• Amazon Cognito documentation: https://docs.aws.amazon.com/cognito/

• Clerk documentation: https://clerk.com/docs