Social login is safe only if the relying party knows exactly which identity it is trusting, and most account takeovers in this area come from linking accounts on an email address instead. When a service lets people sign in with Google, Apple, Microsoft or another identity provider and also offers a local password, it has to decide when two identities belong to the same person. Get that decision wrong and an attacker can sit inside an account before the victim has even created it, or merge their way into an existing one. This guide covers how to key federated identities, when email verification can and cannot be trusted, the account pre-hijacking attack classes, safe linking and unlinking flows, and what to log. It is written for CIAM architects, application developers and security engineers who build or review consumer and business sign-in. For the wider customer identity picture see the Customer IAM (CIAM) Guide.
Key takeaways
- Key every federated identity on issuer plus subject. The
issandsubpair is the stable identifier; email, username and UPN are display attributes that can change or be controlled by someone else. - Never auto-link on a matching email. Require an authenticated session on the existing account, and ideally a fresh authentication, before a new identity is attached.
- Treat email_verified as a claim about the provider, not a fact. Whether you can trust it depends on whether that provider is authoritative for the domain, which differs between consumer, workforce and self-hosted providers.
- Pre-hijacking is an account creation problem. Unverified sign-ups, sessions that survive a password reset and pending email changes all let an attacker prepare an account the victim later adopts.
- Linking events are security events. Log, notify and make every link and unlink reversible, and keep at least one strong authenticator that does not depend on the social provider.
How social login and account linking work
Almost every modern social login is OpenID Connect (OIDC) on top of the OAuth 2.0 authorisation code flow. The relying party (RP) redirects the user to the provider, receives an authorisation code, swaps it for an ID token and then has to answer one question: which local account does this token belong to? There are three common models.
| Model | How the local account is found | Main risk | When it fits |
|---|---|---|---|
| Federated only | Account created on first login and keyed on iss + sub | Lock-in to one provider; recovery depends on the provider | Low-risk apps, single provider, workforce SSO |
| Multiple providers, separate accounts | Each provider identity gets its own account, no merging | Duplicate accounts and user confusion, but no linking takeover | Small services where duplicates are cheap |
| Linked identities | One account with a list of linked iss + sub pairs plus optional password or passkey | Insecure linking and pre-hijacking | Most consumer platforms and SaaS with mixed sign-in |
| Account resolution | Existing records (for example a customer database) matched to a new federated identity by attributes | Attaching data to the wrong person | Migrations, legacy customer bases, regulated onboarding |
NIST SP 800-63C-4 (final, July 2025) describes this as binding a federated identifier to an RP subscriber account. It allows an account to be linked to more than one federated identifier, but states that the RP shall require an authenticated session with the subscriber account for all linking functions, and should require authentication with an existing federated identifier before linking a new one. When an identifier is removed, the RP must stop accepting it. See the NIST SP 800-63C-4 Federation Assurance Levels Guide.
Choosing the right identifier
The OIDC Core specification defines sub as a locally unique identifier that is never reassigned within the issuer. Uniqueness is scoped to the issuer: two providers can issue the same sub to different people. NIST SP 800-63C-4 Section 3.4 makes the same point, describing the federated identifier as the combination of subject and issuer and saying the RP must never process a subject identifier without accounting for the issuing IdP.
| Claim | Stable? | Unique? | Safe use |
|---|---|---|---|
iss + sub | Yes, never reassigned within the issuer | Yes | Primary key for the linked identity |
tid + oid (Microsoft Entra ID) | Yes, immutable | Yes | Microsoft recommends this combined key for application data and access decisions |
email | No, users and tenant administrators can change it | No | Display, contact, a hint for suggested linking only |
preferred_username, unique_name | No | No | Display only |
upn | No, often changes over the user's lifetime | Yes at a point in time | Not for authorisation |
hd (Google Workspace) | Yes for the account | Identifies the hosted domain | Restricting access to members of a specific Google Workspace domain |
- Microsoft Entra ID: Microsoft's claims validation guidance says never to use
email,preferred_usernameorunique_nameto decide access, because they are not unique and can be controlled by tenant administrators or sometimes users. Multi-tenant apps are the worst case: a user in one tenant can set a mail attribute that matches someone else's address. - Google: Google's ID token verification guide says to use only
subas the unique identifier, because one Google Account can have different email addresses over time. - Store the pair, not a hash of email: keep a linked-identities table with columns for issuer, subject, provider name, link date, linking method and last use. This also makes unlinking and incident response straightforward.
ASVS 5.0 requirement V10.5.2 captures this for OIDC clients: identify the user from claims that cannot be reassigned, usually sub, within the scope of the identity provider.
When email verification can be trusted
Linking on email is tempting because it removes duplicate accounts. The problem is that email_verified: true only tells you that the provider believes it verified the address at some point. Whether the provider is authoritative for that address is a separate question.
| Provider situation | Is the provider authoritative for the address? | What to do |
|---|---|---|
Google account with an @gmail.com address | Yes, Google issues the mailbox | Email can be used as a strong hint, still link on sub |
Google account with email_verified true and hd present | Yes, per Google's guidance, it is a Workspace account | As above |
Google account with a non-Gmail address and no hd | No, Google says to use a password or other challenge even if email_verified is true | Do not auto-link; challenge the existing account |
| Microsoft Entra multi-tenant app | Only if the tenant has verified the domain | Never trust email; Microsoft now strips unverified email claims by default for most apps (removeUnverifiedEmailClaim in authenticationBehaviors) |
| Self-hosted or enterprise OIDC provider | Only for domains its operator controls | Allow-list issuer and domain pairs explicitly |
| Provider that does not verify email at all | No | Treat the email as unverified user input |
Microsoft's authenticationBehaviors documentation describes exactly why this matters: email claims are open to privilege escalation when the mail attribute holds an address whose domain owner is not verified, and in multi-tenant apps where a user changes their mail attribute to reach resources in another tenant. Single-tenant apps and multi-tenant apps with prior sign-ins using unverified emails must opt in to the removal by setting removeUnverifiedEmailClaim to true.
A defensible rule: an email match may trigger a suggested link, where the user proves control of the existing account (password, passkey or an emailed one-time link to the address already on file) before the new identity is attached. Auth0's account linking documentation takes the same position, asking for authentication on both accounts before linking, whether linking is manual or automatic.
Account pre-hijacking attack classes
Sudhodanan and Paverd's USENIX Security 2022 paper "Pre-hijacked accounts" studied 75 popular services and found at least 35 vulnerable to at least one of five pre-hijacking attacks. The attacker needs only the victim's email address and acts before the victim signs up. Some variants were visible to an attentive user; others were not detectable from the victim's side at all.
| Attack class | What the attacker does first | Why it works | Control |
|---|---|---|---|
| Classic-federated merge | Registers a password account with the victim's email | Later social login with the same email is merged into the attacker's account, and the attacker's password still works | Verify email before the account is usable; on merge, invalidate local credentials not created by the verified owner |
| Unexpired session | Creates an account and keeps a session open | Victim "recovers" the account with a password reset but the attacker's session survives | Terminate all sessions and refresh tokens on password reset and on first verification |
| Trojan identifier | Creates an account and links an attacker-controlled social identity or phone number | Victim adopts the account; the attacker keeps a back door login | Show and require review of all linked identities after recovery; clear unverified links |
| Unexpired email change | Creates an account with own email, starts a change to the victim's address, never confirms | Victim registers; attacker confirms the pending change later | Expire pending change tokens quickly; cancel them when the address is claimed elsewhere |
| Non-verifying IdP | Uses an identity provider that does not verify email to assert the victim's address | RP trusts the email from that provider and links or logs in | Allow-list providers; trust email only from authoritative providers |
The common root cause is that the service treats an account as owned by whoever holds the email address without having verified that at the moment it matters. CAPEC-21 (Exploitation of Trusted Identifiers) is the closest attack pattern entry, and the end state is ATT&CK T1078 Valid Accounts: the attacker signs in as a legitimate user. For the takeover side of the problem see the Account Takeover Prevention Guide.
Safe linking, unlinking and recovery flows
Linking
- Start from an authenticated session: linking is only offered inside a signed-in session on the existing account (NIST SP 800-63C-4 Section 3.8, OWASP Authentication Cheat Sheet).
- Step up: require a fresh authentication (for example within the last five minutes) with an existing authenticator before the link completes.
- Validate the new identity fully: run the complete ID token validation from OIDC Core Section 3.1.3.7: exact
issmatch,audcontains yourclient_id, signature,exp, andnoncematching the request (ASVS V10.5.1, V10.5.4). - Refuse duplicates: if the
iss+subpair is already linked to another account, stop and route to support rather than moving it. - Notify: send a notice to the verified address and existing devices that a new sign-in method was added (ASVS V6.3.7).
Suggested linking at first social login
- Match found on email: tell the user an account exists and ask them to sign in to it first. Do not reveal more account detail than the sign-in page already does.
- No match: create a new account keyed on the federated identifier.
- Do not silently merge: silent merges are what the classic-federated merge attack relies on.
Unlinking and recovery
- Last-method rule: do not allow the last sign-in method to be removed, and encourage a passkey or password that does not depend on the social provider so the user is not locked out if they lose that account. See the Passwordless and Passkeys Guide.
- Block immediately: once an identity is unlinked, reject logins from it at once.
- Recovery resets everything: a password reset or account recovery should end all sessions, revoke refresh tokens and present the list of linked identities for review. See the Account Recovery and Help Desk Security Guide.
- Email changes: require re-authentication, confirm at the new address, notify the old address, and expire the pending change within a short window.
Protocol hygiene for the sign-in itself
Linking logic is only as safe as the OIDC integration underneath it. RFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025), sets the baseline:
- Exact redirect URI matching: authorisation servers must use exact string matching (ASVS V10.4.1); wildcards in redirect URIs enable code theft.
- PKCE with S256: required for public clients and recommended for confidential ones.
- CSRF protection: one-time
statebound to the browser, or PKCE where the server is confirmed to support it;noncefor ID token replay. - Mix-up defence: an RP that talks to several providers (which is the definition of social login with more than one button) must defend against mix-up attacks, preferably by checking the
issresponse parameter defined in RFC 9207 against the issuer stored for that request, and aborting on mismatch. - No implicit flow: use the authorisation code flow; RFC 9700 says clients should not use response types that return access tokens in the front channel.
- Library, not hand-rolled: both Google and OWASP recommend maintained OIDC libraries rather than custom token parsing.
See the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide and the OAuth 2.0 and OpenID Connect Guide.
Decision guidance
- One provider or many: each extra provider adds a mix-up surface and another email trust decision. Add providers your users actually hold, and keep an explicit issuer allow-list.
- Consumer versus B2B: in B2B SaaS, customers expect tenant-level SSO. Bind each customer tenant to a specific issuer (and for Entra ID a specific
tid) rather than accepting any work account whose email domain matches. - Small services: the simplest secure design is no automatic linking at all, plus a "connect another sign-in method" button inside account settings.
- Large platforms: invest in suggested linking with step-up, a linked-identities admin view for support staff, and fraud signals at sign-up (velocity per email domain, disposable addresses). See the Identity Fraud Prevention Guide.
- Regulated sectors: social login proves control of a provider account, not a real-world identity. Where identity assurance is required, add proofing separately (NIST 800-53 IA-12).
Detection and measurement
- Log every identity event: account created (with method), identity linked, identity unlinked, email change requested, email change confirmed, password reset, all sessions revoked. Include issuer, subject, IP, device and whether step-up was satisfied.
- Alert on patterns: a link followed within minutes by an email change or password change; a new identity linked from a new country; many sign-ups per hour sharing a provider or an email domain; pending email changes to addresses that already exist.
- Support signals: tickets saying "someone else is in my new account" are the classic symptom of pre-hijacking and should be categorised separately.
| Metric | Target or direction |
|---|---|
| Share of links completed with step-up authentication | 100% |
| Accounts usable before email verification | 0, or limited to non-sensitive functions |
| Median age of pending email change tokens at expiry | Hours, not days |
| Sessions surviving a password reset (test result) | 0 |
| Code paths that key accounts on email (code review count) | 0 |
| Accounts with only a social sign-in method | Falling, as users add a passkey |
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-63C-4 | Section 3.4 federated identifiers; Section 3.8 account linking | Issuer plus subject; authenticated session for linking |
| NIST SP 800-53 Rev. 5 | IA-8, IA-2, IA-12, AC-2, SI-4 | Authentication of non-organisational users, proofing, account management, monitoring |
| NIST CSF 2.0 | PR.AA-01, PR.AA-02, PR.AA-03, DE.CM-03 | Identity management, binding, authentication, monitoring |
| OWASP ASVS 5.0 | V10.5.1, V10.5.2, V10.5.4, V10.4.1, V6.3.6, V6.3.7 | Nonce, sub as identifier, audience, redirect matching, email not an authenticator, change notifications |
| MITRE ATT&CK | T1078 Valid Accounts, T1586 Compromise Accounts | Outcome and preparation of linking takeover |
| MITRE CAPEC | CAPEC-21 Exploitation of Trusted Identifiers | Abuse of email as a trusted identifier |
Common failure patterns
- Linking on email in the callback: the OIDC callback looks up users by
email, so any provider that asserts the address gets in. Fix by keying oniss+suband moving email matching into a suggested-link flow. - Usable unverified accounts: password sign-ups work before the address is confirmed, which is the starting point for most pre-hijacking classes.
- Password reset that leaves sessions alive: the reset changes the password but not the refresh tokens or remembered devices.
- Trusting email from every provider equally: a provider that does not verify email, or a multi-tenant workforce provider with unverified domains, is treated like Gmail.
- Tenant SSO keyed on email domain: B2B apps that admit any Entra ID user whose address ends in the customer's domain instead of pinning the customer's tenant ID.
- No notification on link: users never learn that a new sign-in method was added, so a Trojan identifier stays in place for months.
Practitioner checklist
- Store linked identities as
iss+subpairs (ortid+oidfor Entra ID) and remove every lookup by email from sign-in code. - Maintain an issuer allow-list and decide per issuer whether its email claim is authoritative.
- Require an authenticated session and recent step-up for every link, and refuse to move an identity already linked elsewhere.
- Block sensitive use of an account until its email is verified.
- Revoke all sessions and refresh tokens on password reset, recovery and first verification.
- Expire pending email changes quickly and cancel them when the target address registers.
- Notify users on every link, unlink, email change and recovery, and show linked identities in account settings.
- Implement RFC 9700 basics: exact redirect matching, PKCE S256, state and nonce, and RFC 9207
isschecking. - Test the five pre-hijacking scenarios in your QA suite before each release of sign-in code.
Standards and references
- OpenID Foundation: OpenID Connect Core 1.0
- NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- USENIX: Pre-hijacked accounts, An Empirical Study of Security Failures in User Account Creation on the Web
- Microsoft Learn: Secure applications and APIs by validating claims
- Microsoft Learn: Manage application authenticationBehaviors
- Google for Developers: Verify the Google ID token on your server side
- OWASP: Authentication Cheat Sheet
Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Account Takeover Prevention Guide · SAML vs OIDC Guide · Federation and Trust Relationships Guide · Passkey Rollout Guide