The OIDC sub claim is the subject identifier in an OpenID Connect ID token. It is a string that uniquely identifies the end user for a given issuer and client, and it is the main stable identifier used to correlate authentication events without exposing a login name.
What the OIDC sub claim does
The sub claim is the stable subject identifier inside an OpenID Connect ID token. It gives the relying party a consistent way to recognize the same end user across logins without depending on a mutable username or email address.
That stability is the key design point. In OIDC, the login event can change over time, but the sub value is meant to remain the issuer’s unique identifier for that user, so application logic can correlate sessions, records, and access decisions safely.
Why the subject identifier matters in OIDC
The sub claim is not a display name or an account label. It is a protocol identifier that must be treated as the canonical key for a user within the scope of an issuer and client pair. That distinction prevents account collision, user renaming problems, and incorrect merges after federated sign-in.
Because OIDC is built for authentication and identity assertion, the sub claim often becomes the anchor that downstream systems use to link an external identity to an internal account. If that link is based on email alone, a changed address, recycled mailbox, or reused social identity can create misbinding. The OpenID Connect specification defines the core token model, while the broader OAuth 2.0 framework explains the authorization layer around it, and together they form the context for how sub is interpreted.
For teams hardening federation flows, NHIMG’s OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful companion for understanding where the ID token sits in the login flow.
How applications should use the claim
The safest pattern is to store sub as the primary federated user key and treat email, username, and profile claims as attributes, not identity anchors. That keeps account mapping stable even when an upstream provider changes a person’s visible details.
This matters especially in account linking, social login, and multi-issuer environments. If the same person can sign in from more than one provider, the application must distinguish between the issuer and the subject identifier rather than assuming that a matching email means the same account. The OpenID Connect ID token gives the identity assertion, but the application still owns the binding logic.
For federation implementations that depend on exact subject handling, NHIMG’s Social Login and Account Linking Security Guide covers safe linking patterns and the risks of over-trusting email-based correlation.
Common failure modes and why they are dangerous
The most common mistake is to treat sub as if it were globally meaningful outside its issuer scope, or to substitute another claim when the application really needs the stable subject identifier. Either error can lead to broken user mapping, privilege drift, duplicate accounts, or unintended account takeover during link or migration flows.
Another failure mode is weak trust in the surrounding OIDC configuration. If the issuer, audience, token signature, or federation trust is not validated correctly, even a well-formed sub value can be attached to the wrong account. The identifier itself is only as trustworthy as the token validation path that delivers it.
OpenID Connect Core 1.0 defines the token structure and the subject claim model, and the spec is the authoritative reference for how the identifier is supposed to behave across clients and issuers.
For the protocol foundation, OpenID Connect Core 1.0 is the primary specification, and RFC 6749: The OAuth 2.0 Authorization Framework provides the surrounding authorization model that OIDC builds upon.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 3.1.1 — Identity Proofing and Enrollment | OIDC sub depends on reliable subject binding to a verified identity. |
| Recommendation — Bind federated accounts to a verified subject identifier and avoid using mutable profile data as the primary key. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | OIDC sub supports authenticated user identification for enterprise applications. |
| IA-5 — Authenticator Management | Token and federation integrity are necessary for trustworthy subject claims. | |
| Recommendation — Validate the authenticated subject and map it consistently to the correct internal account. Protect token-signing and federation material so subject claims cannot be forged or misused. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OIDC sub is part of the OIDC authentication and federation model covered by ASVS. |
| V8 — Authorization | Applications must use the stable subject claim correctly when enforcing user access decisions. | |
| Recommendation — Verify OIDC issuer, audience, signature and subject binding before creating or linking accounts. Use the subject identifier, not mutable profile fields, to enforce account and authorization binding. | ||