Skip to main content
Identity Authority
Category: Customer Identity

Account Linking

Also known as: User Account Linking
Simply put

Account linking is the process of connecting two or more separate user accounts or identity providers so they resolve to a single user identity. For example, a person who has signed in with a social login and a corporate login can have those combined so both point to the same profile. This helps prevent duplicate accounts and lets a user access their identity through multiple sign-in methods.

Formal definition

Account linking associates multiple distinct identity records or authentication sources with one canonical user profile, typically by designating a primary account and merging or attaching one or more secondary accounts to it. In federated deployments it connects credentials from multiple identity providers (for example social logins and corporate IdPs) to a single account so that different authentication events resolve to the same principal. Implementation details vary by vendor: some platforms merge two existing profiles into one (as in Auth0's primary/secondary model), while others attach a linked account to grant additional capabilities or privileges to a main account (as in CyberArk's linked-account model). Account linking is primarily an identity administration and profile-management concern and does not by itself define runtime authorization; the resulting linked identity governs which authentication sources map to a user, while access decisions remain the responsibility of separate authorization enforcement. Behavior around whether linking merges, replaces, or augments account data depends on the specific product and configuration.

Why it matters

Account linking directly addresses the problem of identity fragmentation. When a single person accumulates multiple separate accounts, for instance, one created through a social login and another through a corporate IdP, organizations end up with duplicate records that point to the same human being. This fragmentation complicates profile management, muddies audit trails, and can leave gaps where one account is deprovisioned while others remain active. By resolving multiple authentication sources to a single canonical identity, account linking reduces duplicate accounts and gives users a consistent identity regardless of which sign-in method they use.

Because account linking sits at the identity administration and profile-management layer, getting it right has downstream consequences for governance and security hygiene. A linked identity determines which authentication sources map to a given user, which in turn affects how completely an identity can be reviewed, updated, or offboarded. Poorly governed linking can also create risk: in privileged access contexts, some implementations (such as CyberArk's linked-account model) attach an account specifically to grant additional capabilities or privileges to a main account, so the linking relationship itself can influence what powerful credentials a user can reach. Treating linking as purely cosmetic understates its impact on the integrity of the identity record.

It is important to note what account linking does not do. Linking itself does not define runtime authorization, access decisions remain the responsibility of separate authorization enforcement. Conflating the act of associating authentication sources with the granting of permissions is a common source of confusion, and the distinction matters when designing controls: linking governs identity resolution, while a separate policy decision governs what the resolved principal is permitted to do.

Who it's relevant to

IAM Engineers and Identity Architects
Those designing federated sign-in and profile-management flows need to decide how multiple identity providers resolve to a single principal. Understanding whether a given platform merges, replaces, or augments account data during linking is essential to avoid unintended data loss or duplicate identities, and to ensure that authentication events from social and corporate sources map correctly.
Identity Governance Leads
Because a linked identity determines which authentication sources map to a user, governance leads must account for linking when scoping access reviews, certifications, and deprovisioning. Fragmented or improperly linked accounts can leave orphaned records that undermine the completeness of a review or leave residual access after offboarding.
Privileged Access Administrators
In privileged access contexts, some linked-account models attach an account to grant additional capabilities or privileges to a main account. Administrators managing these relationships should treat linking as a control that can influence which powerful credentials a user can reach, and govern it accordingly.
Compliance and Audit Officers
Account linking affects the integrity of the identity record and the clarity of audit trails. Officers should understand that linking is an identity administration concern distinct from runtime authorization, and verify that access decisions for a linked identity are enforced by separate authorization controls rather than assumed from the linking relationship itself.

Inside Account Linking

Identity Correlation
The process of associating two or more distinct accounts or identifiers that represent the same principal, typically by matching a shared attribute (such as a verified email) or by an explicit user-driven binding. Correlation is the foundational step that makes linking possible.
Federated Account Linking
Linking a local account to an external identity provider account established through a federation flow, commonly using OpenID Connect (built on OAuth 2.0) or SAML 2.0. The link records the association between the local user record and the external subject identifier returned by the IdP.
Subject Identifier Binding
The persistent, stable identifier the linking relies on to recognize the external account on subsequent logins, such as the OIDC 'sub' claim within a given issuer or the SAML NameID. Depending on configuration, these identifiers are only guaranteed unique within the context of a specific issuer or provider.
Verification of Ownership
The step that confirms the principal genuinely controls both accounts before they are joined, for example by requiring authentication to each account or by a verified-attribute check. This distinguishes a legitimate link from an attacker attempting to attach their identity to a victim's account.
Link Storage and Lifecycle
The persistence and management of the linkage over time, including where the mapping is stored, how links are created, viewed, and unlinked, and how link records are handled during account deprovisioning. In most deployments this is an administrative and governance concern separate from runtime token validation.

Common questions

Answers to the questions practitioners most commonly ask about Account Linking.

Is account linking the same as single sign-on (SSO)?
No. Account linking establishes a persistent association between two or more distinct accounts (for example, a local application account and an external identity provider account) so they resolve to the same principal. SSO is a runtime experience in which a single authenticated session grants access to multiple applications without re-authenticating. Account linking may enable an SSO experience in some deployments, but the two are separate concerns: linking is about relating identities, while SSO is about propagating an authenticated session. You can link accounts without offering SSO, and SSO federations can exist without persistent account linking.
Does linking an external identity provider mean the external provider is authenticating my users going forward?
Not necessarily. Which party performs authentication depends on how the link is configured. When a user authenticates through the linked external IdP, that IdP performs the authentication and your system consumes the resulting assertion or token. However, a linked account may also retain its own local credentials, so authentication can occur locally as well, depending on the flow the user chooses. Account linking records the association; it does not by itself dictate that all future authentication is delegated. Treat the authentication path and the linking relationship as separate configuration decisions.
What identifier should be used to match accounts during linking?
In most deployments, matching relies on a stable, provider-asserted identifier rather than a mutable attribute. For OpenID Connect, the subject identifier (sub), typically in combination with the issuer (iss), is commonly used because it is intended to be stable per user per client. Email address is often available but can be reassigned or change, so relying on it alone for linking can create security and correctness problems. The exact identifier and its stability guarantees depend on the provider and profile, so verify the source provider's documented behavior before treating any claim as a durable linking key.
How can account linking be performed securely to avoid account takeover?
A common approach is to require the user to be authenticated to both accounts being linked before the association is created, so proof of control over each account is established. Automatically linking accounts solely because two providers assert the same email address can enable takeover if an attacker controls an unverified or reassigned address. Depending on your risk posture, you may require verified attributes, step-up authentication, or explicit user confirmation during the linking flow. The appropriate controls vary by deployment and threat model, and out of scope here is any guarantee that a specific provider's assertions are trustworthy without validation.
Where is the account link typically stored and represented?
The association is usually persisted in an identity store or directory as a relationship between a primary account record and one or more external identity references, often keyed by issuer plus subject identifier. Some systems model this as federated identity entries attached to a canonical user profile. The representation is vendor- and deployment-specific; there is no single mandated schema. If SCIM is used for provisioning, external references may be conveyed through configured attributes, but SCIM does not define a universal account-linking mechanism, so the specifics depend on your implementation.
How does unlinking work, and what should be considered before removing a link?
Unlinking removes the association between an external identity and the primary account. Before permitting it, many deployments verify that the user retains at least one other viable authentication method, so removing a link does not lock the user out of their account. Depending on configuration, unlinking may also require re-authentication or step-up verification to prevent unauthorized removal. Consider whether downstream authorization or session state depends on the linked identity, since removing a link can affect how the principal is subsequently resolved. The precise behavior varies by vendor and profile.

Common misconceptions

Account linking authenticates the user, so a successful link means the identity is verified.
Linking is an association between accounts, not an authentication event. Authentication (verifying who the principal is) must occur separately for each account being linked; the link only records that two identified accounts belong to the same principal once ownership has been established.
Matching on a shared email address is sufficient to safely link two accounts.
An unverified attribute match can enable account takeover, where an attacker links their external account to a victim's local account. Ownership of both accounts should typically be proven (for example through authentication or a verified attribute) rather than inferred from an unvalidated identifier.
A subject identifier from an external provider is globally unique, so it can be linked without qualifying its source.
Identifiers such as the OIDC 'sub' claim are typically only unique within the scope of a specific issuer. Linking should bind the identifier together with its issuer/provider context to avoid collisions or cross-provider confusion.

Best practices

Require the principal to authenticate to both accounts, or otherwise prove ownership, before establishing a link, rather than relying on an unverified shared attribute.
Bind links using a stable subject identifier qualified by its issuer or provider (for example the OIDC 'sub' plus issuer), since such identifiers are typically unique only within their source's scope.
Prefer verified attributes over unverified ones when correlating accounts, and treat unverified email matches as insufficient for automatic linking.
Provide users a clear interface to view, create, and unlink their linked accounts, and record link creation and removal for auditability.
Handle link records explicitly during account deprovisioning and lifecycle changes so that stale associations are not left behind.
Keep account-linking logic distinct from runtime token validation, treating link management as a governance and administration concern separate from real-time access enforcement.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide