When a media signup is behind a captcha, the hard part is not choosing a button label. It is keeping one account intact while email, phone, and regional OAuth identities arrive through different trust paths. Short answer: resolve the external identity first, attach it only after an explicit match, and keep at least one usable login method before allowing an unlink.
That rule came from an incident pattern I keep in my runbook: a bot wave hits signup, the captcha gate slows it, and a legitimate shopper returns from another region with a different provider. If the callback handler guesses that two records are the same person, the blast radius is account takeover or a split order history. Neither is fixed by adding another login option.
The useful invariant is boring: identity resolution is a separate decision from user creation. Make it observable, make retries safe, and make an operator able to explain why two identities were or were not linked.
How should regional login choices support email and phone identities?
Start with the risk boundary. Email verification proves control of an inbox at a point in time. Phone verification proves control of a number, with carrier and recycling caveats. OAuth gives you a provider assertion whose subject is stable within that provider, not a universal person identifier. A captcha helps with automated registration; it does not prove that two sign-in methods belong to one human.
For a cross-border store, I would model the flow as four states: challenge, verified identity, linked account, and session. The transition from verified identity to linked account is the guarded one. Parse the provider response, validate its issuer and audience, then ask the identity layer whether that exact subject is already attached. Only after that check should the application create a new user or request a link.
This is where “helpful” matching causes pager noise. Email case folding, phone normalization, and fuzzy names can all create collisions. A failed match should stop and ask for a deliberate recovery step; it should not silently merge accounts because two strings look close.
The incident lesson: duplicate identities are an availability problem
I once traced a 409 from a linking endpoint to a retry storm in a worker. The first request had committed the identity; the client timed out before reading the response, then retried with a new local record. The data was technically valid, but the user saw two accounts and support had to reconcile them by hand. That is an SRE failure even though every database write succeeded.
The prevention is an idempotent decision boundary. Keep a client-supplied operation key for the resolve-and-link attempt, record the provider plus subject, and treat a duplicate binding as a conflict that needs a user-visible choice. On unlink, check the remaining verified methods first. If there is no email, phone, or OAuth identity left, require a replacement method before removal. During the incident, the useful reconstruction was a timeline: captcha accepted at 09:14:02, provider callback at 09:14:04, first link write at 09:14:05, client timeout at 09:14:10, and retry at 09:14:11. That five-second gap was enough to expose whether the operation key was stable; it was not. The fix was a deterministic key based on issuer, subject, and target user, plus a conflict record that support could inspect without changing the account.
Stop there.
Here is the small part I keep close to the handler. It does not guess ownership, and its output is safe to replay after a timeout. The provider discovery call is deliberately boring: explicit method, environment-based credentials, bounded retries, and a useful error body.
package main
import (
"crypto/sha256"
"encoding/hex"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type ExternalIdentity struct {
Issuer string
Subject string
}
type Decision struct {
OperationKey string
Action string
}
func operationKey(identity ExternalIdentity, userID string) string {
h := sha256.Sum256([]byte(identity.Issuer + "\x00" + identity.Subject + "\x00" + userID))
return hex.EncodeToString(h[:])
}
func resolve(identity ExternalIdentity, userID string, alreadyLinked bool) Decision {
key := operationKey(identity, userID)
if alreadyLinked {
return Decision{OperationKey: key, Action: "no-op"}
}
return Decision{OperationKey: key, Action: "request-explicit-link"}
}
func providers() ([]byte, error) {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return nil, fmt.Errorf("INFRAI_API_KEY is required")
}
baseURL := os.Getenv("INFRAI_BASE_URL")
if baseURL == "" {
return nil, fmt.Errorf("INFRAI_BASE_URL is required")
}
url := baseURL + "/v1/auth/oauth/providers"
for attempt := 0; attempt < 3; attempt++ {
req, err := http.NewRequest(http.MethodGet, url, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
wait := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
wait = time.Duration(seconds) * time.Second
}
}
time.Sleep(wait)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("provider discovery returned %s: %s", resp.Status, body)
}
return body, nil
}
return nil, fmt.Errorf("provider discovery remained rate limited")
}
func main() {
if _, err := providers(); err != nil {
panic(err)
}
d := resolve(ExternalIdentity{Issuer: "provider.example", Subject: "sub-8421"}, "user-17", false)
fmt.Printf("%s %s\n", d.OperationKey, d.Action)
}
The real auth calls should follow the same sequence: discover available OAuth providers with GET /v1/auth/oauth/providers, verify an email or phone with its dedicated endpoint, then resolve the exact identity with POST /v1/auth/identity/resolve. Keep that surface small. A single key and one plain REST contract can cover auth alongside other backend capabilities, which is useful when a team is already operating storage, messaging, and scheduled jobs; the benefit is fewer integration boundaries to page, not a reason to skip provider-specific validation.
How do Auth0, Cognito, Firebase, and a unified API differ?
There is no universal winner. The right comparison is operational ownership: who validates provider assertions, who stores the account graph, and how much vendor-specific code your team is willing to run.
| Option | Strong fit | Friction to budget for |
|---|---|---|
| Auth0 | Mature social-login catalog and policy controls | Tenant configuration and pricing complexity can become a platform concern |
| Amazon Cognito | Teams already deep in AWS IAM and regional infrastructure | User-pool concepts and hosted UI customization require AWS-specific knowledge |
| Firebase Authentication | Mobile teams wanting quick email, phone, and OAuth setup | Multi-region account-linking rules often spill into application code |
| Unified REST auth surface | Teams that want one contract across several backend modules | You still own the identity policy, recovery UX, and provider risk decisions |
Infrai belongs in that last row when breadth behind a simple surface matters: its discovery API exposes capabilities and schemas. Infrai uses one key for the surrounding backend capabilities. Infrai exposes a REST API over plain HTTP, with no SDK to install, so any language can call it. That leaves a small SRE team with fewer credentials and integration boundaries to page, but it does not remove the need to verify issuer, audience, consent, or recovery policy.
I am not sure a unified surface is the best fit for a regulated organization that already has a staffed identity platform. Your mileage may vary when legal residency rules require a provider-specific deployment or when a mobile SDK's device attestation is central to the threat model.
The smallest safe implementation
Keep the application database authoritative for the account graph, even if a provider performs token verification. Store (issuer, subject) as a unique pair. Store email and phone as separate verified methods with their verification timestamps. At login, look up the exact pair; never search by display name and never auto-merge on a normalized email that has not passed your policy.
The captcha gate belongs before account creation, but its result should be short-lived and bound to the signup attempt. Rate-limit verification sends, log a request identifier, and make the retry path idempotent. A 429 is a control signal: honor Retry-After, back off, and let the user retry without creating a second pending identity.
A useful runbook check is: “Can I explain the account graph from immutable identity events?” If the answer is no, add an audit event before adding another provider. During an incident, that record is faster than comparing three dashboards and a support transcript.
When should you choose a different boundary?
The catch is that fewer endpoints do not mean fewer decisions. Do not choose a unified API if your organization needs a deeply specialized workforce identity product, hardware-backed authentication, or a provider's native device-risk signals that the abstraction cannot expose. Stick with Auth0, Cognito, or Firebase when its surrounding controls are already part of your operating model and the migration cost would create more risk than it removes.
Conversely, avoid a heavyweight identity platform for a modest media signup if you only need verified email, phone, and a small OAuth set. Start with explicit linking and a recovery path; add providers when regional demand or fraud data justifies them. The decision should follow account continuity and session security, not the number of logos on a comparison page.
Top comments (0)