OAuth issues access tokens for delegated access, but those tokens do not prove who the user is. If teams use OAuth alone for login, they may create sessions without verifying identity, which weakens assurance and can expose applications to impersonation and session abuse. Authentication requires a separate identity protocol, or OIDC when built on OAuth for that purpose.
Why OAuth Tokens Are Not Proof of Identity
OAuth is designed to let a client obtain delegated access to a resource. That means the token proves the client has permission to access something, not that the person signing in is who the application thinks they are. When teams blur that boundary, they turn an authorization protocol into a login mechanism it was never meant to be.
The practical problem is that a valid OAuth access token can be perfectly legitimate while still being the wrong signal for authentication. A system that treats token possession as user proof can create a session before it has established identity, which undermines assurance and makes the application vulnerable to impersonation, account confusion, and session abuse.
This distinction is why authentication and authorization are separate concerns in secure design. OAuth can participate in a login flow, but only when it is paired with an identity layer that returns verified identity claims, such as OpenID Connect Core 1.0. For the underlying delegation model, the protocol itself remains RFC 6749: The OAuth 2.0 Authorization Framework.
How the Security Risk Appears in Real Deployments
The risk usually appears when a development team assumes “token received” equals “user authenticated.” In reality, OAuth access tokens are audience- and scope-bound credentials for a resource server, so their meaning is about access rights. If a product uses those tokens to establish a user session, it may accept delegated access as identity proof and skip the checks that should confirm the user, issuer, audience, and token purpose.
That shortcut creates failure modes that are easy to miss in testing. A token issued for one application can be replayed in another if the trust boundaries are weak, a stolen token can be used until it expires, and a token obtained through a third-party integration can grant access without the application ever validating the user separately. The result is an authentication gap hiding inside what looks like normal authorization handling.
For practitioners, the key technical question is whether the application is validating identity claims from an identity protocol or merely trusting possession of an access token. If the design depends on tokens for login, the implementation should be reviewed as an authentication flow, not just an OAuth integration. The relevant standards for this separation are reinforced by RFC 9700: Best Current Practice for OAuth 2.0 Security and, where proof-of-possession is needed, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession.
What Secure Use Looks Like Instead
Secure implementations keep three ideas separate: who the user is, what the user may access, and what evidence the application relies on. OAuth handles delegated authorization. Authentication must come from a protocol or control set that actually establishes identity, and the application should create its session only after that identity evidence has been validated.
In practice, that means using OpenID Connect for sign-in when the system is built on OAuth, validating the issuer and audience, and rejecting designs that treat an access token as a stand-alone login artifact. It also means being explicit about token scope, token audience, and session lifecycle so that delegated access does not silently become a substitute for identity assurance. Where supported, sender-constrained tokens reduce replay risk and are far safer than bearer tokens alone, as described in RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
The same principle applies to authentication assurance more broadly: a login path should prove identity with the right assurance level for the application, not just accept any credential that can reach an endpoint. For that reason, the identity verification guidance in NIST SP 800-63 Digital Identity Guidelines is a useful reference point when teams are deciding what counts as sufficient proof of identity.
Risk and Threat Considerations
When OAuth is misused as authentication, the main exposure is session creation without verified identity. That can allow impersonation, token replay, privilege confusion, and abuse of delegated access paths, especially when applications trust third-party tokens or fail to constrain the token audience.
Failure mechanism: The application accepts a bearer token as proof of who the user is, rather than as proof of delegated permission, so a valid token can be exchanged for an authenticated session without an identity check.
Impact: Attackers or unintended token holders may gain access as the wrong user, reuse stolen tokens, or move through connected apps and integrations with a session the system treats as authenticated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | OAuth misuse affects whether the app truly authenticates the user. |
| V7 — Session Management | Token-as-login mistakes often create weak or misbound sessions. | |
| Recommendation — Require a real authentication flow before creating a user session. Bind sessions only after validated identity and enforce strict session lifecycle rules. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Identity assurance and authenticators determine whether a login is trustworthy. |
| Recommendation — Use identity assurance guidance to separate proof of identity from delegated access. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User login must establish identity before access is granted. |
| IA-5 — Authenticator Management | Bearer token misuse and replay are authenticator lifecycle concerns. | |
| Recommendation — Authenticate organizational users before issuing an application session. Manage token issuance, storage, rotation, and invalidation tightly. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Authentication secrets and tokens must be protected from misuse. |
| A.5.15 — Access control | OAuth governs access rights, which must not be confused with identity assurance. | |
| Recommendation — Protect authentication information so it cannot be repurposed as login proof. Separate access authorization from user authentication in design and review. | ||
Practitioner Guidance
What to verify: Confirm that every login path produces an identity assertion from a true authentication protocol, and that OAuth access tokens are only used after the user has already been authenticated. If a system cannot explain which component proved identity, treat the design as suspect.
Decision rule: If the token could be presented by an integration, device, or downstream service without proving the end user’s identity, do not allow it to establish the user session. Use OAuth for delegated access and OIDC for sign-in, then bind session creation to validated identity claims.
Practitioner takeaway: The security boundary is not “did we get a token,” it is “did we prove identity before we trusted that token for login.”
