Account linking improves UX but can expose users to account takeover. Learn about key risks, safe design patterns, and how providers like Google and Apple handle email verification.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
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.
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.
Account linking merges or associates user identities from different authentication providers so they refer to the same user account. Three primary approaches exist:
Each approach has distinct UX and security implications.
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.
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.
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.
[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.The remainder of this article details these security risks and effective mitigation strategies.
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.
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.
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.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.
Not all IdPs handle email verification equally. The email_verified OIDC claim (or its absence) is a significant risk factor.
hd claim) are highly trusted. Generic external emails, even if initially email_verified, are less so due to potential ownership changes over time.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.oid (object ID) for linkage and verify emails independently, unless specific claims like xms_edov (Email Domain Owner Verified) are present and true.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.
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.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.
IdPs differ in the risks associated with using their email claims for linking. Here's a brief overview:
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.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.xms_edov) are used. Microsoft advises using the stable oid (object ID) for identity linkage and verifying email independently if needed.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.
When designing account linking, you face an inherent tension between a seamless UX and robust security. The following table compares the approaches:
| Linking Method | User Experience | Security 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.
Designing and implementing secure account linking requires collaboration between development, security, and product teams. Here are recommendations for each:
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.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.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.xms_edov claim, or you might use Microsoft Graph to verify user emails out-of-band.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.By incorporating these guidelines, product and security teams can work together to ensure that account linking enhances user convenience without creating significant vulnerabilities.
Ory Kratos, Ory’s identity platform, provides a security-first approach to account linking, focusing on current capabilities:
sub (subject ID) and relies primarily on email addresses for identification. This process should be handled with care, ideally in controlled migration scripts.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:
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.sub (subject) + iss (issuer) pairs. These are more robust than email addresses, which can change or be reused.