Account linking connects more than one login identity to an application account. A secure linking flow must establish that the user is entitled to connect those identities and that the link does not silently change their business permissions.
An account linking assessment examines the join itself: how it begins, how control of both identities is established, which application account remains primary, and what access persists after unlinking.
Why is a matching email address insufficient evidence?
An email value is an attribute reported by a system. Its meaning depends on verification, issuer behavior, and the application’s trust rules. Treating an email match as automatic permission to merge accounts can skip the question of whether the same person controls both accounts now.
Auth0’s account linking documentation recommends authentication for both accounts before linking. That is a useful starting requirement even when a business uses a different identity platform.
For an illustrative project-management product, a user may have a personal login and a company SSO login. The product needs an explicit rule about whether those identities may be linked and which company’s data becomes available through each login path.
What should the user actually approve?
Show the account being modified and the identity being added. In the project-management example, make the organization and provider clear enough that a customer can distinguish a personal account from a work identity.
Trace the linking request from the signed-in user through the identity-provider callback. Confirm that the server associates the callback with the intended linking operation and account. A successful provider login should not accidentally complete an unrelated pending link.
Use two controlled browser sessions and synthetic accounts to observe that association. Do not use real employee accounts or introduce an unapproved login method into production.
Which negative cases should the assessment include?
Test cancellation, an expired linking request, a callback arriving in the wrong session, and an attempt to attach an identity already linked elsewhere. For each, define whether the application rejects the operation or takes the user through a separate recovery process.
Include the successful case with both identities authenticated. Record the application account identifier before and after the link, the connected provider identities, and the resulting login behavior. Avoid retaining access tokens in the evidence.
If automated migration links accounts, review that path separately. A secure user-facing screen does not establish that an import job applies equivalent ownership rules.
What happens to roles and company memberships?
Write down whether linking combines memberships, preserves only the primary account’s permissions, or requires administrator action. Then test the stated behavior with two synthetic accounts that have different roles.
For example, a personal account might be a viewer in one project while the work account administers a company workspace. Verify which login paths can exercise the administrator role after linking and whether that result matches the company’s SSO policy.
Identity continuity and business authorization are separate decisions. A convenient combined profile should not silently bypass an organization’s required login method.
How should unlinking and recovery work?
Remove the secondary identity in the test environment and check fresh sign-in through that provider. Also examine any sessions created before removal according to the product’s documented revocation policy. Confirm that the legitimate user retains an approved recovery path.
For Ceron, request a lifecycle record covering link, cancellation, role handling, unlink, and recovery. Retest the affected sequence after a fix, including the normal successful journey.
SSO domain claims examines organization onboarding, while email change security covers changes to a recovery identifier. The project-management example is illustrative.
