Why do OAuth2 access tokens create risk when teams treat them as proof of login?

Why This Matters for Security Teams

OAuth2 access tokens are often treated as proof of login because they look like portable credentials and are easy to pass between systems. That shortcut creates audience confusion: a token issued for one API can be replayed in another trust boundary if the receiving app mistakes authorization for authentication. The result is not just a technical error, but an identity control failure that can enable impersonation, lateral movement, and session substitution.

This matters because the abuse pattern is already well documented in real incidents, including the Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, where token trust assumptions became the attack surface. The NHI issue is wider than one application layer: NHIMG research on The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes misuse harder to spot and faster to spread.

Security teams usually do not discover the mistake during design reviews. In practice, many teams encounter it only after a token meant for API access has already been accepted as a login credential in production.

How It Works in Practice

The safe model is to separate authentication from authorization. OpenID Connect is the common pattern for authentication because it issues an ID Token that is intended for the client application and can be validated for issuer, subject, audience, and nonce. OAuth2 access tokens, by contrast, are meant for resource servers and should be checked only where the protected API understands the scope and audience of the token.

Operationally, this means the receiving application should validate four things before trusting any token:

• Is the token intended for this application or API audience?
• Was it issued by a trusted issuer and signed correctly?
• Is it still within its lifetime and not revoked?
• Does the token type match the purpose of the exchange?

That last check is where many implementations fail. A front-end app that accepts an access token as proof of login is skipping the identity layer and collapsing two trust decisions into one. The same confusion appears in partner integrations, service-to-service calls, and agentic workflows where a system passes tokens across tools without preserving the original audience. Guidance from OWASP Non-Human Identity Top 10 aligns with this risk: token handling must be bound to explicit identity and access boundaries, not convenience. NIST control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce that identity proofing, access enforcement, and session management are distinct functions.

In environments with multiple apps, federated SaaS, or embedded third-party integrations, the problem becomes harder because the token may be valid in one hop and meaningless in the next. These controls tend to break down when teams reuse access tokens across clients, because the audience check is no longer enforced at the boundary where the token is consumed.

Common Variations and Edge Cases

Tighter token validation often increases integration overhead, requiring organisations to balance developer convenience against stronger boundary enforcement. The biggest edge case is confusion between user-facing login flows and machine-to-machine authorization. If a service account, browser client, or embedded widget receives an access token, that token still does not prove the end user authenticated to that app unless the protocol explicitly supports that exchange.

Current guidance suggests treating token format as insufficient evidence on its own. Even a signed JWT can be misused if the audience, issuer, and purpose are not checked. That is especially important for supply chain and third-party SaaS scenarios, where the same OAuth app may be connected to many tenants and the blast radius of a stolen token is broader than a single session. NHIMG case research such as the Vercel Context.ai OAuth Supply Chain Breach shows how quickly an apparently narrow integration can become a cross-tenant exposure path.

Best practice is evolving toward shorter token lifetimes, explicit audience restriction, and server-side policy checks at request time. The practical takeaway is simple: use OIDC ID Tokens for login, use OAuth2 access tokens for API authorization, and never let a client infer identity from a token whose purpose is only delegation.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why do static credentials create more risk than short-lived access tokens?
• Why do service accounts and tokens create more risk than many teams expect?
• Why do service accounts and access tokens create more breach risk than human accounts?