What is the difference between using sub and using email as the account identifier in OIDC?

Why sub is the durable account key in OIDC

OIDC gives you two different kinds of data: a stable subject identifier and a human-facing profile attribute. The stable identifier is what you should use for account matching because it is issued by the provider as the canonical reference for that issuer-subject pair. This matters most when the same person can have multiple emails, or when an email changes over time.

That distinction is why account binding should be built around the identifier that the issuer intends to remain stable, not around a contact attribute that can change for operational reasons. When implementations blur those roles, they tend to create account-linking errors, duplicate accounts, and recovery edge cases that are hard to unwind later.

For the protocol basis, OpenID Connect Core 1.0 defines the claim model that separates subject identity from profile data, and the rule of thumb is to treat those two categories differently in your application logic.

Why email is useful, but unsafe as the primary identifier

Email is often the most convenient value to display, search, or use for notifications, but it is not a reliable account key. A mailbox can be renamed, transferred, shared, replaced, or become unavailable, and the same email address can also be verified in one context while remaining weakly trusted in another. That makes email useful for communication and secondary checks, not for durable identity resolution.

The practical danger is that teams treat a verified email as proof of account continuity. In reality, email can be a mutable attribute tied to a delivery channel, while the OIDC subject is the claim designed for persistent binding. If you use email as the primary identifier, you inherit all the lifecycle problems of inbox ownership and provider-specific policy changes.

OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful companion here because it explains how OIDC claims, tokens, and client types fit together when you need to separate authentication data from user profile data.

How to design account linking, recovery, and change handling correctly

The safe design pattern is simple: bind the local account to iss plus sub, then treat email as a mutable attribute that may support display, communication, or step-up checks. If the email changes, update the profile record after revalidation, but do not silently rebind the account itself. If you support multiple identity providers, preserve the issuer boundary so that identical emails from different providers do not collapse into one account.

This also affects recovery flows. If a user proves control of an email address, that does not automatically mean they should inherit the same OIDC account identity unless your recovery policy explicitly and safely reconciles the provider subject with your local record. Good implementations also log when the email changes, when the linked subject changes, and when an account merge is attempted, because those are the events most likely to expose linking mistakes or abuse.

Social Login and Account Linking Security Guide is directly relevant because it covers issuer plus subject matching, email verification trust, and safer account-linking flows.

Risk and Threat Considerations

Using email as the account key increases the chance of account confusion, takeover-by-linking mistakes, and accidental merges when a mailbox is reassigned or the address is updated. The weakness is not just inconvenience, it can create an authorization problem if the wrong local record inherits the wrong federated identity.

Failure mechanism: the application treats a mutable email attribute as if it were a stable federated subject, so a changed, reused, or ambiguously verified address can map to the wrong account or overwrite the right one.

Impact: users can lose access, attackers can gain unintended access through broken account linking or recovery, and audit trails become unreliable because the account history no longer reflects the original OIDC subject.

Practitioner Guidance

What to verify: Confirm that your application stores and indexes the issuer and subject together, and that email is never the sole lookup key for login, linking, or recovery. Test the exact cases that usually fail in production: email changes, provider switching, duplicate emails across issuers, and missing email claims.

Decision rule: If you need a durable account identity, use iss plus sub; if you need a contact path or a human-readable label, use email. If a business process insists on email-first matching, treat that as a design exception that needs explicit compensating controls, not as the default architecture.

Practitioner takeaway: In OIDC, the identifier should be the thing you trust to stay the same, while email should be treated as a useful but changeable attribute that must never be allowed to redefine account ownership.

Related resources from NHI Mgmt Group

• Guide: Identity Provider and SSO Security Guide
• Why does relying on email as the unique identifier create account takeover risk in OIDC?
• Why does using an email claim for account linking create takeover risk in Microsoft OAuth apps?
• What is the difference between using a device identifier and using login context to secure account access?
• What is the difference between using an OAuth email claim as a login identifier and treating it as a verified attribute?