account merging flow

[jaspermayone]

Why

hackclub/auth#51 says it best: "everybody uses 50 different emails." People WILL sign up twice under different addresses; duplicate identities poison OAuth grants, Slack links, and verification status. Multi-email support (#12) is the prevention; merging is the cure for the duplicates that happen anyway.

What

• Admin-initiated (and possibly user-requested) merge of identity B into identity A:
  • both accounts must verify ownership (magic-link/2FA challenge on each, or step-up (step-up re-authentication for sensitive actions #87) when self-service)
  • migrate: secondary emails (add Email (support multiple emails) #12), OAuth grants/tokens (dedupe per application), sessions (revoke B's), Slack link, verifications (id verification framework (verification models, status claim, hosted vendor, nfc later) #97), addresses, activity/audit history (retain with provenance)
  • B becomes a tombstoned alias: its emails resolve to A at login, its public IDs redirect where safe
• Merge is itself a heavily audited, reason-required admin mutation (reason-required admin mutations with a semantic admin activity feed #93), likely break-glass-gated (break-glass access records for admin access to sensitive user data #92)
• Duplicate detection surface (same name+DOB, shared IP/fingerprints — see hackclub/auth's ResemblanceNoticerEngine) can suggest merge candidates later.

Reference

• account merging flow hackclub/auth#51 (their open want)
• https://github.com/hackclub/auth/blob/main/app/services/resemblance_noticer_engine.rb

Notes

Merging is where public-ID stability matters: downstream services hold usr_/PWL ids for both accounts. Decide the alias/redirect story before implementing.