Keep sign-in identities attached to one account
A person can use an external identity without becoming a different application user each time. Wildo records the link between the provider’s identity and the local account.
Account controls let people inspect and remove their permitted sign-in links. Wildo checks ownership and removal policy, and refuses a removal that leaves no established sign-in method enabled for the account.
Example — Keep the same account after adding a provider
A member signs in through an approved external provider and continues with their existing application account and memberships.
For engineers
Store the identity relationship, not another user
The identity-link record connects the local userId to a provider reference and provider subject, with the relevant connection/scope context. Social and enterprise provisioning create or resolve those links as part of their own verified sign-in flows.
An external identity link is not an outbound connected-account credential for calling a vendor API. It answers who is signing in, not whose third-party token an integration spends.
Keep removal on the authenticated owner’s path
AuthMethodManagementBackendService.unlinkIdentityLink and passkey removal share one transaction-owning guard. It enforces removal policy, serializes removals on the account’s credential record, removes the exact owned target, then evaluates the state that would remain. If no established first factor survives, the transaction rolls back.
This excerpt is the decision inside that transaction. remove performs the specific identity-link or passkey mutation; every participant receives the same transaction options.
const locked = await this.repositoriesRegistryHandler.atomicGuardedMutation<UserCredentials>(
CoreResourceType.USER_CREDENTIALS,
{ _id: credentials._id, userId },
{ increment: { _version_db_doc: 1 } },
ec,
options,
);
if (!locked) throw this.errorBuilder.buildError(ErrorType.CONFLICT, ec, {
context: { reason: 'Credential record changed during removal' },
});
await this.enforceUserMethodRemovalAllowed(ec, userId, options);
const result = await remove(options);
await this.authMethodSurvival.assertSurvivingFirstFactor(ec, userId, options, frontendServiceName);
return result;
A stored password counts only when enabled. Enrolled passkeys, supported passwordless routes and established external sign-in routes are evaluated against their current policy and configuration. A SCIM provisioning record or a TOTP second factor does not replace a first factor. The guard also does not assume that a provider will recreate a deleted link through email matching later.
The credential version used for serialization is separate from the user’s authorization version, so the guard does not revoke sessions merely to coordinate removals. A missing link and another person’s link both produce not-found. The success audit follows the committed removal.
This protects established first-factor routes; it does not guarantee message delivery, provider availability, completion of MFA or administrator recovery. Stored-method inventory remains available separately from this safety decision.
Preserve the provider’s verified identity
Do not create links by trusting an email string supplied by a browser. Provider callbacks own subject verification and any permitted email-based linking. Removing a local link does not delete the external provider account, delete the application user or automatically change organization membership. Your interface should name the action as removing a sign-in method.