The sub claim is the authoritative, locally unique identifier that the issuer promises not to reassign, so it is suitable for durable account binding. Email is a user attribute that may be verified, changed, absent, or inconsistent across providers. In practice, sub should anchor identity matching, while email should support communication or secondary checks.
Why OIDC Account Identifiers Are Not Interchangeable
The difference matters because an OIDC account identifier is the key used to bind a real person or workload to a durable local account record. The Ultimate Guide to NHIs — What are Non-Human Identities is useful background when teams are also thinking about machine identities, but the same principle applies here: the identifier must be stable, unique within the issuer, and safe for lifecycle changes. Email often looks convenient because humans recognise it, but it behaves like profile data rather than an identity anchor.
That distinction affects account creation, matching, deprovisioning, and federation trust. If a team binds access to email, they are assuming the address will remain present, verified, and exclusive to one identity across time and providers. That assumption fails in common cases such as email changes, alias reuse, multiple accounts sharing one mailbox, or providers that do not assert email at all. The OIDC sub claim exists specifically to avoid that problem. In practice, many integration defects appear only after a user changes address or a federation boundary is crossed, not during the first login.
How Identity Binding Works in Practice
In OIDC, sub is the subject identifier asserted by the issuer. It is the stable value a relying party should store as the foreign key for account linkage. Email can still be valuable, but it should be treated as an attribute that supports notification, search, or a secondary verification step, not as the primary identity key.
A safe implementation usually follows a simple pattern: first authenticate the OIDC token, then bind the local account to iss plus sub, and only then evaluate profile fields such as email, name, or department. The issuer matters because sub is only unique within that issuer, so combining issuer and subject prevents collisions across tenants or identity providers. If the application supports account linking, the operator should require explicit proof of continuity before merging identities that share an email address.
Use
subfor durable matching and database keys.Use email for display, messaging, recovery workflows, or soft matching only.
Reconcile changed email addresses as profile updates, not as a new identity by default.
Store issuer context with every federated identity record to prevent cross-issuer collisions.
This approach aligns with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises controlled identity lifecycle handling, and it is especially important when identity data is reused across applications. These controls tend to break down when an organisation treats email as a unique identifier across multiple identity providers because the same mailbox value can move, alias, or be reassigned while the underlying account relationship stays different.
Common Edge Cases and Failure Modes
Tighter identity matching often reduces convenience, so teams must balance user simplicity against account integrity. The practical tradeoff is that sub-based binding is less human-readable, while email-based binding is more intuitive but far more fragile.
There are a few cases where the difference becomes operationally visible. Some providers emit no email claim, some users have unverified email, and some enterprise directories permit aliases that look stable but are not authoritative. In federation migrations, a user may keep the same email address while the issuer changes, which means the old local account should not be trusted solely because the mailbox string matches. The reverse also occurs: a user may change email while remaining the same subject, and a system that keys on email may accidentally create a duplicate account or orphan entitlements.
When this pattern is mishandled, the risk is account confusion rather than just a cosmetic data issue. Wrong-account sign-in, duplicate entitlements, and failed deprovisioning are the usual downstream symptoms. For that reason, current guidance suggests treating email as a mutable claim and sub as the canonical binding value whenever the application is relying on OIDC for account identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | OIDC identifiers determine account binding and access decisions. |
| Recommendation — Bind federated accounts to issuer plus subject before granting access. | ||
| NIST SP 800-63 | AAL2 — Identity Assurance Level 2 | OIDC account identity depends on trustworthy asserted identity attributes. |
| Recommendation — Verify asserted identity attributes before using them for account recovery. | ||
| CIS Controls v8 | 6.3 — Access Grants and Revocation | Wrong identifier choice can misgrant or fail to revoke user access. |
| Recommendation — Use authoritative identifiers to remove stale access when attributes change. | ||
| NIST Zero Trust (SP 800-207) | 4.2 — Policy Decision Point and Enforcement | OIDC identity claims should drive context-aware authorization decisions. |
| Recommendation — Evaluate identity claims consistently at the policy decision point. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Misbound identities can let access persist through account confusion. |
| Recommendation — Hunt for valid-account abuse when identifier drift causes account ambiguity. | ||
Practitioner Guidance
What to verify: Confirm that the application stores both issuer and sub as the primary identity key, and that email is never used alone to locate an existing account. If a developer or IAM team cannot explain how account linking survives an email change, the binding logic is probably unsafe.
Decision rule: If the identifier is used to grant access, preserve entitlements, or recover an account, require iss plus sub. If it is used for communication or a helpdesk lookup, email is acceptable as supporting metadata but not as the source of truth.
What practitioners underestimate: The biggest failure is not a single bad login; it is identity drift over time. A system that works during pilot onboarding can silently misbind users after provider migration, domain consolidation, or email reassignment.
Practitioner takeaway: Durable identity matching should follow the issuer’s stable subject claim, while email should be treated as a changing attribute that can assist people but should not define the account.
Related resources from NHI Mgmt Group
- What is the difference between storing TOTP codes in a password manager and using a standalone authenticator app?
- What is the difference between short-lived workload tokens and long-lived service account keys for cloud application access?
- What is the difference between using a primary directory account as the anchor for hybrid authentication and maintaining separate cloud and on-prem identities?
- What is the difference between passwordless authentication and intelligent authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
