Connecting existing accounts without exposing account state

Adding an email invitation sounds like a small product feature. It becomes a security design problem when the same address might belong to a new user, an existing user or someone who already belongs to another family.

I encountered that boundary while extending a family-management application. Parents could already create a child profile and invite a new email address to claim it. The next requirement was to let an existing app account connect to that profile without resetting its password, changing its sign-in methods or creating a duplicate family member.

This field note describes the design decisions behind that workflow. Real email addresses, invitation values, environment details and organization-specific identifiers are intentionally omitted.

Start with the privacy question

A straightforward implementation could check whether an email exists and tell the parent which path will be used. That would also turn the form into an account-discovery endpoint.

The parent-facing response therefore stays neutral:

const connectionSuccess =
  "If this email can be connected, a secure link has been sent.";

The browser does not learn whether the address is registered. Exact-email account lookup happens only on the server through an administrative client, and the lookup operation is unavailable to anonymous or ordinary authenticated database roles.

Neutral messaging is only one layer. The authorization rules still have to reject invalid requests, but they do so without exposing unnecessary account state to the person initiating the invitation.

Separate new-account and existing-account paths

The two account modes need different authentication behaviour:

• A new address receives an invitation and creates credentials during acceptance.
• An existing account receives a passwordless sign-in link and keeps its current credentials.