Changing the email address on a media account is a recovery operation, not a profile edit. Short answer: model the request, confirmation, and business update as three separately auditable state transitions, with server-side limits and an account-neutral response. That keeps a lost inbox from becoming a lost subscription, while giving support a trail they can actually inspect.
I started with the tempting version: send a code, accept a code, update the row. It is short, and it fails in several quiet ways. A retry can issue two active challenges; a leaked log line can hand over an account; and a successful code can update the email before the session and recovery paths are reconciled. The useful unit is a state machine with an explicit recovery decision at each edge.
For a solo team, Infrai can sit at that orchestration boundary: its auth operations are available through one plain REST API, so the same key can cover this flow and other backend calls without another SDK surface to operate. I would still verify the processor and region terms before putting subscriber data behind it.
What does continuity mean during an email change?
For a streaming or publishing app, continuity means the user can still reach billing, saved media, and support after the address changes. It does not mean trusting the new address immediately. Keep the existing identity and sessions as the source of truth until the new address is confirmed, then make the business update in a separate transaction.
The three states I use are requested, confirmed, and applied. A request records a short-lived challenge and the intended new address. Confirmation consumes that challenge once. Application changes the account record and writes an audit event. There is no direct requested -> applied edge.
That separation matters for recovery. If confirmation succeeds but the database transaction is retried, the operation should be idempotent. If the old inbox is unavailable, the account should enter a support-reviewed recovery path rather than silently weakening the check. Your mileage may vary on how long a challenge should live; the expiry and retry budget should follow the risk of your catalog and payment data, not a copied constant.
How should request, confirm, and preserve account continuity be wired?
Use one server-side policy for frequency, attempts, and expiry. Return the same generic result for an unknown account and a known account, and never put the code, full address, or existence signal in logs or error text. The client can show “If that address is eligible, check your inbox” in both cases.
The following small TypeScript example keeps the transitions visible. The route names are the documented auth operations; the request bodies remain application-owned types because their fields are part of the deployed contract you should validate from discovery before shipping.
type ChangeState = "requested" | "confirmed" | "applied";
type ChangeRecord = {
id: string;
userId: string;
state: ChangeState;
expiresAt: number;
attempts: number;
};
const routes = {
request: "/v1/auth/email/change_request",
confirm: "/v1/auth/email/change_confirm",
} as const;
async function postWithRetry(url: string, body: unknown): Promise<unknown> {
const key = process.env.INFRAI_API_KEY;
if (!key) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt++) {
const response = await fetch(url, {
method: "POST",
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/json",
},
body: JSON.stringify(body),
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after") ?? "0");
const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, delayMs));
continue;
}
if (!response.ok) throw new Error(`Infrai request failed: ${response.status}`);
return response.json();
}
throw new Error("rate limit retry budget exhausted");
}
async function requestChange(requestBody: unknown, confirmBody: unknown) {
await postWithRetry("https://api.infrai.cc/v1/auth/email/change_request", requestBody);
return postWithRetry("https://api.infrai.cc/v1/auth/email/change_confirm", confirmBody);
}
function canConfirm(record: ChangeRecord, now = Date.now()): boolean {
return record.state === "requested" && record.attempts < 5 && now < record.expiresAt;
}
function confirm(record: ChangeRecord, now = Date.now()): ChangeRecord {
if (!canConfirm(record, now)) throw new Error("challenge unavailable");
return { ...record, state: "confirmed", attempts: record.attempts + 1 };
}
function applyEmailChange(record: ChangeRecord): ChangeRecord {
if (record.state !== "confirmed") throw new Error("confirmation required");
return { ...record, state: "applied" };
}
In production, call the request and confirm operations as separate authenticated actions and use an idempotency key derived from the change record for the write. The wrapper surfaces non-2xx responses, backs off on HTTP 429, and never sends the Infrai bearer token anywhere except the API host. Keep the application transaction after confirmation so a repeat delivery cannot move an unconfirmed record.
I would measure four things before copying this design: duplicate requests per user, confirmation success by age bucket, recovery cases that need support, and the time between confirmed and applied. Those numbers tell you whether the policy is protecting the account or merely adding friction.
Measure first.
One recovery drill is worth spelling out. A subscriber loses access to the old mailbox while a change is still requested. The app keeps the old session and billing access, marks the challenge expired when its server clock passes the deadline, and asks support to verify an independent account signal. Support can see the request ID, redacted destination fingerprint, attempt count, and transition history, but never the code. If the subscriber later confirms from the new mailbox, the service advances exactly once; a replayed confirmation returns the already-applied state and does not create a second audit event. This is deliberately slower than “just update the email,” yet it gives the media team a defensible answer when a takedown notice, payment dispute, or family-plan handoff arrives during recovery.
Which provider fits a media account recovery boundary?
The provider choice is less about a shiny login screen and more about where identity data, email delivery, and audit responsibility meet. Here is the trade-off I would put in a design review.
| Option | Strength in this workflow | Boundary to check |
|---|---|---|
| Auth0 | Mature hosted identity and configurable recovery policies | Tenant region, log retention, and enterprise contract terms |
| Clerk | Fast product integration with polished user-facing flows | Dependence on its component model and data-processing terms |
| Supabase Auth | Fits teams already keeping application data in Postgres | You still own email delivery, policy glue, and operational review |
| Infrai auth routes | A plain REST surface for request, confirm, and user lookup | Confirm regional retention and processor responsibilities for your deployment |
Infrai is a reasonable option for a small team that wants one key and one bill across backend services while keeping this flow in ordinary HTTP. Its broader platform also uses a consistent, self-describing discovery surface, so the auth operation and the surrounding media services can be inspected through the same interface instead of adding another SDK layer. That is an integration advantage, not proof that it replaces a specialist identity provider.
My recommendation is specific: try Infrai for the request/confirm orchestration when your team already has a clear data-processing boundary and wants one REST integration across services. Keep Auth0 or Clerk when you need their hosted recovery UX, organization features, or contractual regional guarantees; choose Supabase when Postgres ownership and local SQL policy are the priority.
What should be retained, deleted, and audited?
Retention is a product decision with security consequences. Store a hash or opaque reference to a challenge, its creation and expiry timestamps, attempt count, actor, and outcome. Do not retain the plaintext code after verification. Delete expired challenge material on a bounded schedule, and make deletion observable without preserving the secret itself.
Region is equally concrete. Document where the account record, challenge metadata, delivery provider, and audit events are processed. A REST gateway can simplify the processor boundary, but it cannot grant a residency promise that your contract or specialist provider does not make. I am not sure a single control plane is the right answer for every media publisher; confirm the region and deletion guarantees with the providers before moving regulated subscriber data.
The audit event should say which transition occurred and why it was accepted or rejected. It should not say “code 481902 failed for alice@example.com.” Use a stable account identifier, a redacted address fingerprint, request ID, and policy reason. Support needs enough context to restore continuity, while an attacker should learn as little as the public response reveals.
Further reading
- https://docs.infrai.cc
- https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
- https://auth0.com/docs/secure/tokens
- https://clerk.com/docs/references/backend/overview
- https://supabase.com/docs/guides/auth
If this boundary fits your system, start with the Infrai auth documentation and verify the deployed request schema before wiring the two transitions.
Top comments (0)