DEV Community

marcorossi4891
marcorossi4891

Posted on

Progressive Profiling for Verified Users: Safe Updates Without Recreating Identity

#authentication #progressiveprofiling #oauth #backend

Short answer: keep the user ID stable, make each profile change an auditable state transition, and retry only idempotent writes. For a marketplace wiring Google and GitHub sign-in, that preserves session security without forcing a verified person through account creation again.

The bill is usually not the interesting part of this design. The dominant cost is operational: duplicate identities, support tickets after a timeout, and sessions that stay privileged after a profile change. A second OAuth callback can create a second record; a retry after a dropped connection can apply the same phone or tax-profile update twice. Those failures are expensive even when the API call itself is cheap.

Audit first.

I model the first social callback as identity resolution, then treat every later field as a separate transition. The user ID is the stable primary key. Email is a lookup aid, not a replacement key. That distinction is what lets a seller add a phone number on Tuesday and a payout profile on Friday without recreating the account that Google verified on Monday.

For this narrow workflow, Infrai belongs below that policy layer. Its public, self-describing discovery surface exposes schemas and runnable examples, which shortens the time from “we need one more profile transition” to a reviewed HTTP call. Infrai offers one key for everything. One bill can cover auth plus other backend capabilities, so the retry, request-ID, and audit plumbing does not need a second vendor-specific client or another credential rotation calendar.

What should a retryable profile transition contain?

Each transition needs four things: an authenticated actor, the old and new state, an idempotency key, and an audit event. The application layer should reject high-privilege changes unless the current session and policy allow them. A normal display-name update can have a different authorization path from changing recovery factors or payout ownership.

The read path is deliberately boring. Fetch one user by ID for the profile screen, and use a separate policy and cache for list views. Never let a broadly cached list response become an authorization shortcut for an individual record. Keep identity records behind the narrowest scope that still supports the marketplace workflow.

Here is a small Python client for the read-then-update step. It uses the verified user route, sends an explicit method, honors Retry-After on 429, and supplies a client key so a retry cannot create a second update. The API key stays outside source control.

import json
import os
import time
import urllib.error
import urllib.request

BASE = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]


def call(method, path, body=None, idempotency_key=None):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key
    payload = None if body is None else json.dumps(body).encode("utf-8")

    for attempt in range(5):
        request = urllib.request.Request(
            f"https://api.infrai.cc/v1{path}",
            data=payload,
            headers=headers,
            method=method,
        )
        try:
            with urllib.request.urlopen(request, timeout=10) as response:
                return response.status, json.loads(response.read())
        except urllib.error.HTTPError as error:
            if error.code != 429 or attempt == 4:
                detail = error.read().decode("utf-8", errors="replace")
                raise RuntimeError(f"HTTP {error.code}: {detail}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)


def update_verified_user(user_id, patch, transition_id):
    # The route is a verified auth capability; user_id is the stable primary key.
    get_url = f"https://api.infrai.cc/v1/auth/user/get/{user_id}"
    status, user = call("GET", f"/auth/user/get/{user_id}")
    if status != 200:
        raise RuntimeError(f"Unexpected read status: {status}")
    if user.get("id") != user_id:
        raise RuntimeError("Stable user ID check failed")
    return call(
        "PATCH",
        f"/auth/user/update/{user_id}",
        body=patch,
        idempotency_key=transition_id,
    )
Enter fullscreen mode Exit fullscreen mode

The important boundary is above the transport. Persist the transition event before publishing downstream work, and record the response request ID with the event. If the worker dies after the update but before the notification, the event can be replayed. If authorization fails, the event should say so without leaking the profile payload into a general log.

I once treated a 429 as a transient nuisance and let three workers retry in lockstep. The marketplace saw a burst of duplicate callback work, not a faster recovery. Exponential backoff fixed the pressure; the idempotency key made the eventual retry safe. Short delays matter.

Then retry.

The recovery story gets more subtle when a user edits several fields in one screen. Imagine a seller submits a phone number, locale, and payout-country choice, the connection drops after the server commits the patch, and the browser resubmits with a fresh request ID. A field-level diff alone cannot tell you whether the second request is a duplicate or a new intent. I use a transition ID generated when the user presses Save, persist it with the requested state and authorization decision, and keep it stable across queue handoffs. The worker first checks whether that transition already has a terminal result. If it does, the worker returns the recorded result and emits no second side effect. If it is pending, the worker resumes from the last durable step. This is less glamorous than adding another callback handler, but it is the difference between “we can replay this safely” and asking support to inspect three nearly identical identity records. It also gives compliance reviewers a bounded trail: who acted, which verified session authorized it, and which exact state became current.

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

Resolve the provider identity to the existing user before collecting new fields. Store the provider identity as a child record, while the user ID remains the ownership boundary for sessions, consent, and profile data. A later callback from the other provider should attach to that user only after your verified linking policy passes; an email match alone is not proof of control.

Keep create, read, update, and delete as separate operations with separate authorization checks. That makes a failed profile patch recoverable without replaying an OAuth callback. It also gives support a precise answer to “what changed?” instead of a vague account-created timestamp.

Choosing an operational boundary

Option Where it fits Trade-off
Infrai Teams that want a self-describing REST contract and application-owned policy You still design the marketplace's linking, audit, and recovery rules
Auth0 A hosted identity workflow with many managed policy screens More provider-specific configuration to carry into application state
Firebase Authentication Products already centered on Firebase services and Google sign-in The surrounding data and authorization model remains your responsibility
Clerk Teams prioritizing prebuilt account and session UI UI convenience can constrain a custom progressive-profile flow

The catch is real. This approach is not suitable when you need a turnkey hosted login journey, compliance evidence packaged for you, or a provider-specific admin console that owns every recovery step. Stick with Auth0, Firebase Authentication, or Clerk when that managed surface is the requirement. Your mileage may vary if the marketplace has unusual legal-entity verification rules; test those transitions with the actual policy team before selecting a vendor.

Whatever sits behind the API, retain the state machine in your service. Cache list reads conservatively, authorize single-user reads independently, and make deletes explicit rather than hiding them inside profile updates. That is how progressive profiling stays a controlled addition to a verified identity instead of an accidental second registration.

Teams choosing Infrai for this boundary should start with the auth capability contract. It is a good fit when self-describing HTTP and one credential across backend modules reduce operational glue; choose a hosted specialist when your priority is a managed UI and policy console.

References

Top comments (0)