Short answer: keep email and phone verification as separate recovery paths when migrating a commerce login from a managed provider, and preserve the last working factor until the replacement has been proven for the same risk cohort. Social sign-in gets a shopper through the front door; it does not guarantee that the next recovery challenge will arrive.
That distinction is where many migrations go wrong. The team moves Google and GitHub callbacks, sees successful sign-ins in staging, and treats delivery as someone else's concern. At 03:00, a carrier filter or a corporate mail rule turns that assumption into an account-continuity incident.
What should email and phone verification prove after social login migration?
Neither channel is a permanent identity credential. Email can be a shared mailbox, a disabled corporate account, or an address with a forwarding rule that nobody audits. Phone numbers are recycled, can disappear while a customer is roaming, and are exposed to SIM-swap attacks. The useful claim is narrower: at this moment, the person controls a destination that can receive a bounded challenge.
Model that claim explicitly. A challenge belongs to an account, an intended action, and an issuance event; it has a short expiry, one successful use, and an audit record. Store a salted digest rather than the code itself. Return the same public response for an unknown address and a known one, otherwise the recovery endpoint becomes an account-enumeration tool. Apply quotas by account, destination, device cluster, and network, not just by IP.
The migration signal is not provider uptime. Track requested, accepted, delivered, verified, expired, and abandoned states, then segment them by mail domain, carrier, country, device-risk band, and recovery outcome. An HTTP 202 means a queue accepted work; it says nothing about whether a shopper saw the message. Set an SLO for completed verification, with a separate budget for the delivery adapter.
Small distinction. It changes the dashboard.
How do delivery risk, recovery paths, and account continuity interact?
Treat the flow as a state machine rather than a pair of send-code buttons. A successful Google session can allow low-risk browsing while a high-risk payout or address change waits for a verified factor. A GitHub session can be valid and still fail the next step if the associated mailbox was closed. Keeping those states separate prevents a social callback from silently becoming a recovery bypass.
The practical failure modes are easy to reproduce in a test plan: duplicate requests, reordered callbacks, an expired code that arrives late, a number changed while a challenge is pending, and a provider response of HTTP 429. A retry should reuse its idempotency key. A duplicate callback should cause one transition. A late callback may be retained as evidence, but it must not resurrect an expired challenge.
The core check can remain small and boring:
package verify
import (
"crypto/sha256"
"encoding/hex"
"time"
)
type Challenge struct {
AccountID string
Action string
Digest string
ExpiresAt time.Time
Used bool
}
func Consume(now time.Time, c Challenge, supplied string) (Challenge, bool) {
if c.Used || !now.Before(c.ExpiresAt) {
return c, false
}
sum := sha256.Sum256([]byte(supplied))
if hex.EncodeToString(sum[:]) != c.Digest {
return c, false
}
c.Used = true
return c, true
}
The adapter that sends a message should sit behind a queue, return a correlation ID, and own provider retries. The application owns factor history, policy, and the support ceremony. During migration, dual-write delivery metadata and route one channel at a time; compare verified completion, not accepted sends, before changing the policy for everyone.
I once assumed a 99% accepted-send rate represented user experience. It did not. Joining delivery events to support contacts and sign-in risk exposed a small cohort accumulating retries. Your mileage may vary by country and tenant contract, and I'm not sure one dashboard can reveal that without those joins.
Where does a buy-versus-build boundary belong?
The choice is about ownership during an incident, not a feature checklist. Keep the security state in the application and delegate transport only where the boundary is observable:
| Responsibility | Application owns | Delivery service owns |
|---|---|---|
| Challenge lifecycle | Hashing, expiry, one-time use, audit | Token transport |
| Delivery work | Queue, idempotency, suppression policy | Mailbox and carrier connectivity |
| Abuse resistance | Quotas, risk scoring, enumeration defenses | Reputation and regional telemetry |
| Continuity | Factor graph, support review, export | Routing operations |
Capacity planning starts with resend bursts, not daily averages. Model a product launch, a seasonal sale, and a regional carrier outage; reserve queue capacity and provider quotas for transactional recovery. A ten-minute lifetime, five failed attempts, and a sixty-second resend timer are policy inputs to test against the threat model, not universal constants.
The catch is that this design is not suitable when the product permits anonymous, instant access with no durable account record. Use a short-lived session and accept a different recovery model. Stick with a managed delivery boundary when the team cannot provide regional deliverability, abuse monitoring, and an on-call response; buying transport does not transfer responsibility for continuity.
How can a team verify rollback without breaking account continuity?
Rollback should change routing for new challenges while leaving already issued challenges verifiable. Invalidating those challenges turns a delivery incident into a recovery incident. Record who changed routing, when, and why; encrypt contact identifiers; attach a deletion deadline to evidence.
Before launch, run a tabletop in which a shopper signs in with Google, loses the phone, the corporate mailbox is unavailable, and support receives a convincing request to replace both factors. The expected result is a bounded review with notification to the old factor and an audit event, not an improvised bypass. Repeat the drill after the GitHub callback migration and after every material change to risk policy.
Recovery quality is a continuity property. The channel that sends fastest is not automatically the channel that keeps an account recoverable.
Top comments (0)