What do teams get wrong when they treat access tokens as proof of identity?

Teams often assume any valid token proves who the user is, but access tokens only authorize access to a resource and can be acquired through machine-to-machine flows or refresh exchanges. OIDC separates that from authentication by issuing an ID token that confirms the user’s sign-in. Confusing the two weakens trust decisions and can expose systems to improper access.

When access tokens are treated like identity proof, what breaks?

Access tokens are usually authorization artifacts, not proof that a particular person successfully signed in. They show that a client is allowed to call a resource under a granted scope, but they do not, by themselves, establish how the token was obtained or whether the original authentication step was strong enough to trust a user-facing decision.

The practical mistake is to collapse two different trust questions into one: “is this caller allowed to use the API?” and “who actually authenticated?” In OpenID Connect, that separation matters because the ID token carries authentication claims, while the access token is meant for resource access. When teams ignore that distinction, they can build brittle trust checks, mis-handle token replay, or accept delegated or machine-issued access as if it were direct user proof.

That confusion becomes more serious in modern integrations because tokens can move through refresh flows, service-to-service exchanges, brokered sessions, and third-party tooling. A valid token may indicate an authorized path, but not the identity context a product team thinks it has. For a broader identity lens on why token handling, scope, and lifecycle matter, see Ultimate Guide to NHIs and the related NHI guidance on what are Non-Human Identities.

Why token type and token audience matter operationally

An access token is issued for a resource server and is validated for audience, scope, expiry, and issuer. Those checks support authorization, but they do not answer the authentication question on their own. If a team uses an access token as a surrogate for identity, it may skip the step that should validate the user session, federation result, or sign-in assurance level.

That distinction is especially important when the same application handles both browser logins and backend API calls. A user can authenticate once, yet the application may later receive a token minted for a different client, a different audience, or a different grant path. Good design keeps those contexts separate so the application does not infer user identity from a bearer artifact that was only meant to authorize access.

It also matters for downstream trust decisions such as step-up authentication, session continuity, and audit trails. If the application cannot tell whether a token came from a human sign-in, a machine workflow, or a token exchange, it cannot safely use that token as the basis for “this user did it” conclusions. For real-world token abuse patterns, the Salesloft OAuth token breach and the Internet Archive breach both show how exposed or stolen tokens can be abused without proving a legitimate user session.

How to keep authentication evidence separate from authorization tokens

The cleanest pattern is to treat the ID token, session state, or equivalent authentication record as the source of sign-in evidence, and the access token as the permission artifact for the resource. That means the resource should validate token audience and scope, while the application should separately preserve the authentication context it needs for user experience, consent, policy decisions, and incident review.

Teams also need to verify the exact grant flow they are using. An access token delivered through authorization code flow, refresh exchange, or service-to-service delegation can represent different assurance conditions, even if the token format looks similar. The right question is not “is the token valid?” but “valid for what action, on whose behalf, and under what authentication evidence?”

For implementation teams, a useful habit is to explicitly document which claims are safe to use for authorization and which claims, if any, are appropriate for identity assertions. That prevents fragile logic such as using token presence, token freshness, or token issuer alone as proof of a user’s sign-in. When the subject is authentication assurance rather than token mechanics, NIST SP 800-63 Digital Identity Guidelines remains a useful reference point for the evidence that should underpin authentication decisions.

Risk and Threat Considerations

When teams confuse access tokens with proof of identity, they widen the chance of unauthorized access, privilege confusion, and false attribution. The failure is not only technical, because a token that was valid for one resource, client, or delegation path can be mistakenly trusted as evidence of a stronger sign-in than actually occurred.

Failure mechanism: The application or API skips separate authentication verification and treats a bearer token as a user identity assertion, so stolen, replayed, exchanged, or delegated tokens can pass a trust decision they were never meant to satisfy.

Impact: Attackers or unintended clients can gain improper access, incident responders can misread who performed an action, and governance teams can lose confidence in logs, step-up rules, and session-bound controls.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V10 — OAuth and OIDC	OIDC token handling and token type separation are central to this question.
Recommendation — Validate ID tokens for sign-in evidence and use access tokens only for authorized API access.
NIST SP 800-63	Digital Identity Guidelines	Authentication assurance and federation evidence determine whether a sign-in can be trusted.
Recommendation — Separate authentication evidence from authorization tokens before making identity-based decisions.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	User authentication evidence must be distinct from access authorization artifacts.
	IA-5 — Authenticator Management	Token and secret handling affects whether bearer artifacts can be misused or replayed.
Recommendation — Require authenticated user context before trusting actions that depend on identity. Manage token lifecycle tightly and revoke or rotate credentials when trust is uncertain.
OWASP API Security Top 10	API2 — Broken Authentication	Mistaking access tokens for identity proof is an authentication design failure.
Recommendation — Verify authentication separately from API authorization and do not infer identity from bearer tokens.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Token-based non-human and delegated flows can be trusted incorrectly when authentication context is lost.
Recommendation — Bind token use to the correct authentication context and reject assumptions that a valid token proves identity.

Practitioner Guidance

What to verify: Check whether your code paths explicitly distinguish authentication evidence from authorization evidence. If a control decision depends on “who signed in,” the access token should not be the only artifact you inspect.

Decision rule: If the token is being used to justify user-facing trust, elevated actions, or account attribution, require a separate authentication record, such as the ID token or session state, before you rely on it.

Common mistake: Teams often validate token signature and expiry, then assume the token itself proves the user. That is enough for resource access checks, but not enough for identity assertions or sensitive workflow decisions.

Practitioner takeaway: Treat access tokens as permission objects, not identity proof; if your control model needs to know who authenticated, preserve and verify that evidence separately.