Everything you need to know about secure account linking

Account linking allows users to connect multiple login methods—such as email/password, Google Sign-In, or Apple Sign-In—to a single user account. This capability improves UX by allowing users to sign in with different providers interchangeably. However, you must implement linking carefully to avoid serious security risks.

Summary

This article examines the technical and security aspects of various account linking approaches: manual linking, link-on-login prompts, and automatic linking. We analyze their user experience (UX), security trade-offs, and explore known risks like domain spoofing, email reuse, weak OpenID Connect (OIDC) claims, and dangling domains, while citing IdP verification practices from Google and Apple. We also offer guidance for developers, security architects, and product managers on safe implementation, using Ory’s platform as an example. These concepts are key for effective federated identity management.

Understand approaches to account linking

Account linking merges or associates user identities from different authentication providers so they refer to the same user account. Three primary approaches exist:

• Manual user-initiated linking: Users explicitly connect accounts through a settings or profile page after they've logged in.
• Link-on-login (suggested linking): If a user tries to log in with a provider and an account with the same identifier (typically email) already exists, the system prompts the user to confirm ownership and link the accounts.
• Automatic linking: The system automatically merges or associates accounts with matching emails across providers, without any user prompt.

Each approach has distinct UX and security implications.

Explore manual account linking (user-initiated)

Manual linking requires users to actively connect another login method to their existing account, usually through an account settings or profile page. Users must authenticate with both their current account and the new provider to prove ownership before the link is established.

• Security: This method is very secure because it's entirely user-driven. It requires prior authentication and typically re-confirms the user's intent, minimizing the risk of accidental or malicious linking. The linking action itself must also be protected (e.g., by requiring re-authentication).
• User Experience: The main downside is reduced convenience. Users might not discover or use this feature due to the extra steps and potential additional logins. If users unknowingly create multiple accounts, those accounts remain separate and can cause confusion until manually linked.
• Use cases: This approach is common in high-security applications or enterprise environments where explicit user consent and low implicit trust are paramount. It's also essential for allowing users to manage their linked social logins. Ory’s platform, for instance, supports manual linking to give users full control.

Understand link-on-login prompts (suggested linking)

Link-on-login, or suggested linking, is a more dynamic approach. The system detects when a user attempts to log in with a method whose identifier (usually email) matches an existing account. Instead of creating a new account or rejecting the login, the system prompts the user to confirm ownership of the existing account and merge the credentials. For example, if a user signs in with Google, and an account with their email already exists (perhaps created with a password), they might be asked for their existing password to link the accounts. Auth0's documentation notes this requires authenticating the account to which the new provider will be linked.

• Security: Link-on-login is significantly safer than automatic linking because it requires users to prove ownership via an existing credential or another verification step. This acts as a second-factor verification at the moment of linking. Ory Kratos uses this method to prevent account takeovers. The security of this approach depends on the strength of the verification step; a weak method (like an email one-time password (OTP) sent to an already compromised address) would be insufficient. Users should also be encouraged to verify a site's authenticity before responding to such prompts to mitigate phishing risks.
• User Experience: This method adds a minor delay to the login process, but only when a duplicate email is detected. Clear communication (e.g., "For your security, please confirm your password to link your Google account") helps users understand the step and appreciate not ending up with duplicate accounts. Overall, link-on-login provides a good balance between convenience and security and is used by platforms like Ory Kratos and often preferred over silent linking by frameworks such as NextAuth.js.

Evaluate automatic account linking (auto-merge)

Automatic linking merges accounts with matching identifiers (usually email) across different providers without any user prompts. This offers the most frictionless experience, as users don't need to remember their original login method or manage duplicate profiles.

• Security: This is the riskiest approach if not handled with extreme care. By silently merging accounts, the system treats external IdP assertions (like email claims) as sufficient proof of identity. This assumption can lead to account hijacking if an attacker can claim the victim's email on another provider or exploit weaknesses in email verification.
  • Example: John has an app account created with [email protected] and a password. An attacker registers [email protected] on a less secure third-party IdP ("ACME OAuth"). The attacker then uses ACME social login on John's app. If automatic linking is enabled, the system might merge the ACME identity into John's account, granting the attacker access. Historical vulnerabilities, such as those related to some "Sign in with Microsoft" configurations or Flickr's past Cognito setup, exploited such unverified email linking. Consequently, automatic linking between arbitrary providers without robust safeguards should generally be disabled. Frameworks like NextAuth.js highlight this risk with flags like allowDangerousEmailAccountLinking. If you implement auto-linking, do so only when you have high trust in the IdP's email verification processes and domain control.
• User Experience: The sole advantage is a seamless, zero-friction login. However, the significant security risks and the potential for incorrect or malicious merges often outweigh this convenience. Silent linking can also confuse users who might have intentionally wanted separate accounts.

The remainder of this article details these security risks and effective mitigation strategies.

Identify security risks of automatic account linking

Automatic linking is dangerous because it relies on external attributes, like email addresses, as proof that two accounts belong to the same user. If these attributes can be spoofed, duplicated, or compromised, an attacker can deceive the system into linking their account to a victim's account.

Risk: Domain spoofing and impersonation

A key risk involves the domain part of email addresses. Naively trusting that identical email strings mean the same person overlooks how easily attackers can spoof or misuse domains in certain identity systems. For example, Microsoft Entra ID allows tenant administrators to set a user's email or User Principal Name (UPN), often without requiring default verification for that email address. This could enable impersonation if an application automatically links accounts based on this unverified email. Even within Google’s ecosystem, Google Workspace emails (e.g., [email protected]) are trusted differently than standard Gmail accounts; Google is not authoritative for non-Gmail/non-Workspace emails unless an hd (hosted domain) claim is present, even if the email was initially verified. Major IdPs like Google and Microsoft offer signals (e.g., Google’s email_verified claim combined with an hd claim, or Microsoft’s xms_edov claim) to indicate the trustworthiness of an email. If these signals are absent or false, user confirmation should be required before linking.

• Mitigations: Always check the IdP’s stance on an email’s domain. For Google, email_verified=true combined with an hd claim for a Workspace domain is a positive signal; otherwise, treat the email as unverified for auto-linking. For Microsoft Entra ID, consider requiring the xms_edov claim or using the Microsoft Graph API to remove unverified emails from tokens. If an email's domain isn't definitively under the IdP’s control, assume it could be compromised and fall back to a user-mediated linking flow.

Risk: Email address reuse and recycling

Even if an email was legitimately verified for a user initially, it might not always remain under that user’s control. Email reuse is common: people leave organizations, students graduate, and personal addresses are abandoned. These email addresses can later be reassigned. If a recycled email address (e.g., [email protected]) is used with a social login, an application might automatically link it to the original Alice's account, thereby compromising it.

• Mitigations: Never auto-link solely based on a matching email without current proof of ownership. A link-on-login prompt requiring a password or second factor acts as this proof. Email-based verification for linking can also be risky if the email account itself is compromised. Treat matching emails as hints that need to be verified, not as definitive proof of ownership.

Risk: Unverified or weak OIDC email claims

Not all IdPs handle email verification equally. The email_verified OIDC claim (or its absence) is a significant risk factor.

• Google: Verifies primary emails. Gmail and Google Workspace emails (with an hd claim) are highly trusted. Generic external emails, even if initially email_verified, are less so due to potential ownership changes over time.
• Apple: Sign in with Apple provides only verified emails; the email_verified claim is always true for emails Apple shares, making its ecosystem generally robust for email trust. "Hide My Email" relay addresses are also Apple-verified.
• Microsoft: Microsoft Entra ID often doesn't mark emails as verified by default in tokens. It's crucial to use the user's oid (object ID) for linkage and verify emails independently, unless specific claims like xms_edov (Email Domain Owner Verified) are present and true.
• Other IdPs: Providers like Okta, GitHub, and Facebook have varying practices. Some may not verify email at all or may not provide an email_verified claim. For these, assume an email was "verified once, possibly long ago," unless the IdP guarantees ongoing control.

The SlashID blog advises relying on the sub claim for identity and verifying email addresses independently when high assurance is required.

• Mitigations: Always honor the email_verified flag when present; never auto-link if it’s false. For IdPs like Microsoft Entra ID that don’t supply it by default, assume the email is unverified unless specific claims (e.g., xms_edov=true) indicate otherwise. Check for provider-specific claims like Google’s hd or Microsoft’s xms_edov. When in doubt, prompt the user for verification.

Risk: Dangling domains and expired email addresses

A subtle threat comes from dangling DNS records or expired domains associated with email addresses. If a user signs up with an email on a custom domain (e.g., [email protected]) and that domain registration later expires or its MX (mail) records are misconfigured, an attacker could potentially take over the domain. This would allow them to receive any emails sent to that domain, including verification emails for account linking or password resets, potentially leading to account takeover. Detecting dangling domains from within your application is challenging.

• Mitigations: Limit the damage from potentially compromised domains by using short-lived email confirmations for linking, sending user notifications for all linking events, and encouraging users to keep their contact information up to date. The safest approach remains a user-driven checkpoint in the linking process, requiring re-authentication or another form of verification that an attacker controlling a lapsed domain would likely not possess. This is a principle Ory Kratos employs.

Review how major identity providers verify emails

IdPs differ in the risks associated with using their email claims for linking. Here's a brief overview:

• Google: Generally reliable for verifying emails. Google is authoritative for Gmail addresses and Google Workspace domains (when an hd claim is present and email_verified=true). For other external emails linked to a Google account, Google warns that ownership might have changed since initial verification, even if email_verified is true.
• Apple: Sign in with Apple requires the user’s Apple ID email to be verified. The email_verified claim is always true for emails Apple provides, including those through its private relay service ("Hide My Email"). This offers high confidence for consumer email verification.
• Microsoft: Microsoft Entra ID and Microsoft Accounts (MSA) can be complex. MSA usually verifies email at creation. However, Microsoft Entra ID, often used for organizational sign-ins, may not verify an email by default unless specific configurations and claims (like xms_edov) are used. Microsoft advises using the stable oid (object ID) for identity linkage and verifying email independently if needed.
• Others (Facebook, LinkedIn, Twitter, etc.): These providers generally verify email during account signup but might not include an email_verified flag in standard OAuth data. The risk with these is primarily about email reuse or outdated information. Assume the email was "verified at least once, possibly years ago," unless the IdP explicitly guarantees ongoing control.

Summary of IdP practices: Google (for Gmail/Workspace) and Apple provide the highest confidence in email validity for linking. Microsoft Entra ID can offer high confidence if configured to use claims like xms_edov, but not by default. Other IdPs vary. For every IdP you integrate, understand its specific behavior regarding email verification claims. Always implement fallback verification methods if an IdP doesn’t provide strong guarantees. As a rule, never rely solely on an email claim for critical linking decisions without either robust IdP assurance or your own independent verification.

Achieve balance between security and user experience

When designing account linking, you face an inherent tension between a seamless UX and robust security. The following table compares the approaches:

Linking MethodUser ExperienceSecurity Considerations

Manual Linking	High friction – user must actively link via settings; requires multiple steps.	Very safe – user-driven with authentication on both accounts. Minimal risk. (Low convenience, High security)
Link-on-Login Prompt	Medium friction – extra step only if matching account found; user prompted to verify.	Safe if properly implemented – user proves ownership, blocking most attackers. Risk if verification is weak. Balanced. (Moderate convenience, High security in practice)
Automatic Linking	No friction – transparent to the user.	Risky – relies on external IdP claims. Vulnerable to spoofing, unverified emails, & reuse. Use only in controlled scenarios with high trust. (High convenience, Low security unless carefully restricted)

The table shows that as convenience increases, security often decreases if no additional protective measures are implemented. Manual linking, while safest, can be cumbersome for users and may not scale well for consumer applications. Link-on-login offers a popular compromise: it introduces a minor hurdle that most legitimate users can clear but effectively thwarts many attackers. Approach automatic linking with extreme caution, restricting it to scenarios where you have very high confidence in the identity assertion (e.g., linking between two methods you fully control, or within a highly trusted security domain). Auto-linking between arbitrary social providers is generally not worth the risk.

Achieving balance might also involve giving users and administrators choices. Some applications allow users to decide whether to link accounts or keep them separate. Others prioritize safety by default, only linking accounts when users opt in or when specific security conditions are met. The increasing adoption of passkeys and other biometric authentication methods may also influence these flows, potentially offering strong, user-friendly ways to assert identity that could simplify aspects of secure account management, though their direct application to linking disparate IdP accounts requires careful consideration.

Follow implementation guidance for secure account linking

Designing and implementing secure account linking requires collaboration between development, security, and product teams. Here are recommendations for each:

Guidance for identity platform developers

• Use stable identifiers internally: Design your identity model to use provider-specific unique IDs (OIDC sub + iss pairs) as the primary keys for linking logic, not email addresses. The sub (subject) claim, unique within an iss (issuer), forms a globally unique and stable identifier for that user-IdP relationship, handling email changes and reuse more robustly.
• Enforce identifier uniqueness or map carefully: Decide if your system allows multiple accounts with the same email. Often, enforcing email uniqueness is preferable to prevent duplicates, thereby triggering a linking flow instead of new account creation when a known email is encountered.
• Implement secure linking flows: Provide functionality for both manual linking (via account settings, requiring re-authentication) and suggested linking (link-on-login with robust challenges like password entry or MFA).
• Make automatic merging an opt-in feature: If you support fully automatic linking, make it opt-in and clearly label it as potentially dangerous (e.g., NextAuth.js’s allowDangerousEmailAccountLinking: true flag). The default should be off. Consider scoping any auto-linking to specific, trusted providers or only when certain claims (like Google Gmail account status) are present.
• Incorporate IdP-specific checks: Build logic to check for email_verified and similar signals from IdPs (e.g., Google's hd, Microsoft's xms_edov). Your linking policy should reflect the nuances of each IdP you support.
• Log and monitor linking events: Treat account linking as a sensitive operation. Log all linking events (providers involved, user IDs) for auditing, debugging, and potentially for user-facing activity logs.
• Test for abuse cases: As part of security testing, simulate attacker scenarios. For example, try to link into an account using an IdP that allows setting an arbitrary email. Ensure your verification prompts effectively block unauthorized linking. Engage bug bounty programs or external security reviewers to probe your linking mechanisms.
• Consider advanced scenarios: For complex architectures like microservices or integrations with multiple internal IdPs, explore standards such as OAuth 2.0 Token Exchange (RFC 8693) for secure identity propagation and assertion.

Guidance for security architects

• Define an acceptable risk level: Work with product and development teams to determine if the convenience of automatic linking outweighs the risks in your specific context. In many cases, you'll likely conclude that automatic linking without user verification is too high-risk and should be disabled or heavily restricted. Document this decision.
• Leverage IdP controls and configurations: If your product integrates with customer-provided IdPs (common in enterprise scenarios), consider requiring those IdPs to provide verified emails or implement domain validation. For instance, when integrating with Microsoft Entra ID, you might require customers to configure their tenant to send the xms_edov claim, or you might use Microsoft Graph to verify user emails out-of-band.
• Implement extra out-of-band verification for high-security needs: In environments demanding high security, you could require any linking action (even link-on-login) to be approved through a separate channel, such as a notification to the user’s trusted mobile device.
• Plan for account recovery and unlinking: From a security perspective, establish clear and secure procedures for unlinking accounts and for recovering accounts that might have been improperly linked. Ensure that attackers cannot easily unlink legitimate recovery methods or link malicious ones. This might involve re-verification of identity.
• Educate teams and enforce best practices: Ensure developers understand the critical importance of checking email_verified and similar IdP claims. Code reviews and security assessments should flag any instances where account linking or merging occurs without proper verification checks.

Guidance for product managers and UX designers

• Make security part of the UX narrative: When introducing account linking, understand that a small amount of friction for a security step is generally acceptable to users if it's clearly explained. Ensure that any prompts (like asking for a password during a link-on-login flow) have friendly, non-technical explanations. Clearly communicate what is happening and why, especially for linking errors or unexpected states.
• Provide clear account management options: Give users the ability to manually link and unlink accounts in their profile settings. This caters to user preference and also serves as a fallback if automatic or suggested linking doesn't occur as expected.
• Avoid unintended merges by considering edge cases: Think about scenarios like family members sharing an email address (rare, but possible) or users who deliberately maintain separate personas with the same email (e.g., using email aliases). If your application might cater to situations where one email address doesn't uniquely identify one person, you may want to opt out of automatic linking entirely.
• Feature flag and roll out linking changes carefully: If you're introducing new account linking features or changing existing behavior, roll them out gradually if possible. Use feature flags to control a new linking flow and monitor for user confusion, spikes in support tickets, or suspicious login attempts.
• Educate users about account linking: A short help article or FAQ explaining "How do I link my accounts?" or "Why am I being asked for my password when logging in with Google?" can preempt user confusion. Emphasize both the convenience benefits and the security rationale.
• Consider user notifications for linking events: As an added UX safety measure, consider emailing or otherwise notifying the user when a new login method is linked to their account (e.g., “Your account was just linked with a Google login. If this wasn’t you, please secure your account here.”).
• Address privacy implications: Account linking involves consolidating user data. Ensure your implementation complies with relevant privacy regulations like GDPR. Be transparent with users about what data is being linked and obtain necessary consents for processing this data.

By incorporating these guidelines, product and security teams can work together to ensure that account linking enhances user convenience without creating significant vulnerabilities.

Review Ory’s approach to secure account linking

Ory Kratos, Ory’s identity platform, provides a security-first approach to account linking, focusing on current capabilities:

• Manual linking supported by default: Users can explicitly link different authentication methods to their account via settings, ensuring full user control.
• Suggested linking (link-on-login) supported by default: When a user signs in with a social provider and their email matches an existing account, Ory Kratos prompts them to prove ownership (e.g., by entering their password) before linking. This secure flow is the default. An optional configuration allows hiding login hints; this can harden against account enumeration but may slightly degrade UX by not guiding users to their existing login methods.
• Automatic linking for imported users (migration scenarios): Ory Kratos Enterprise supports automatic linking via its admin API for users imported during a migration. This is particularly useful when the original user data lacks a stable provider-specific sub (subject ID) and relies primarily on email addresses for identification. This process should be handled with care, ideally in controlled migration scripts.
• Core security principles maintained: Ory Kratos consistently mitigates common attack scenarios by requiring additional credential prompts for linking. It also emphasizes robust email verification processes and configurable trust settings for external IdP email claims.
• No automatic linking between arbitrary social providers: By default, Ory Kratos does not automatically merge two social provider accounts even if they share the same email, as there's no common secret (like a password) to robustly verify ownership for linking in such scenarios. Manual linking remains the secure path here.
• Consideration for broader automatic linking: Full automatic linking for end-users with trusted providers (like Google Workspace/Gmail or Apple) under specific, highly secure conditions (e.g., strong guarantees of email ownership and domain control from the IdP) is under consideration.

Conclusion: Implement secure and user-friendly account linking

Secure account linking presents a nuanced challenge, balancing user experience with robust security. Careless linking based solely on a shared email address can expose users to account takeover through impersonation, unverified claims, or recycled emails. The stakes are high, as a successful malicious link can grant an attacker full account access.

To design account linking correctly, adopt a trust but verify approach. Embrace the convenience of single sign-on, but rigorously verify that the person attempting to link is the true account owner at every critical juncture. This often means introducing a small amount of friction, such as a password prompt or a confirmation click, at the moment of linking. Evidence from industry incidents and expert recommendations consistently points to the necessity of this extra verification step.

By understanding the technical details of OIDC claims and IdP behaviors, and by planning for known threats like domain spoofing and email reuse, you can implement account linking that is both user-friendly and secure. Major identity providers like Google, Apple, and Microsoft Entra ID offer signals and features to aid in this, but it's the responsibility of application developers and architects to use them correctly. Whether you're building on a platform like Ory or developing a custom solution, the core principles remain: exercise caution with automatic trust, implement robust verification checks, and keep the user informed throughout the process.

Ultimately, a well-implemented account linking system enhances your product’s usability—allowing users the flexibility to log in as they prefer—while steadfastly maintaining the integrity and security of their accounts. By following the best practices outlined in this article, you can offer the convenience of multiple login options without compromising on security.

In summary:

• Prioritize security over convenience: Automatic account linking without robust user verification is highly risky and can lead to account takeovers. Link-on-login with an explicit verification step (like a password prompt or MFA) offers a strong balance.
• Verify email claims from external IdPs: Don't blindly trust email addresses. Check for verification signals (e.g., email_verified, Google's hd claim, Microsoft Entra ID's xms_edov claim). Understand each IdP's email verification policies and perform your own verification when in doubt.
• Use stable identifiers for internal linking: Rely on immutable, provider-specific identifiers like OIDC sub (subject) + iss (issuer) pairs. These are more robust than email addresses, which can change or be reused.
• Understand IdP nuances in email verification: Major IdPs like Google, Apple, and Microsoft have different approaches to email verification and domain trust. Tailor your linking logic accordingly.
• Ensure user control and transparency: Provide users with clear options to manage their linked accounts. Communicate any linking prompts or actions transparently to build trust and reduce confusion.