How should security teams decide when to use access tokens versus ID tokens?

Use access tokens when the application needs to authorise an API call or resource action, and use ID tokens when the client needs proof that authentication succeeded for a specific subject. The key decision is purpose. If a token is being used to grant access, it must be treated as an access token and validated accordingly.

Why This Matters for Security Teams

Choosing between access tokens and ID tokens is not a naming exercise. It is an authorisation boundary decision. An access token should be treated as a bearer credential for an API or resource action, while an ID token is evidence that a client authenticated a subject. Mixing those purposes weakens validation, makes privilege assumptions ambiguous, and creates a path for token replay or misuse across trust boundaries.

This matters most in NHI-heavy environments where service-to-service calls, agent workflows, and delegated access are normal. Security teams often see token handling drift into convenience patterns, especially when developers copy examples without checking audience, issuer, and intended use. The result is a token that “works” in testing but is accepted too broadly in production. NHI Management Group has repeatedly shown how token exposure and lifecycle failures become breach amplifiers, including in the Salesloft OAuth token breach and the Guide to the Secret Sprawl Challenge. Current guidance from the OWASP Non-Human Identity Top 10 aligns with this: treat token purpose as a control requirement, not a documentation detail.

In practice, many security teams only discover the difference after an ID token is mistakenly accepted at an API gateway or a bearer token is reused far beyond its intended audience.

How It Works in Practice

The decision starts with the consumer of the token. If the caller is a client application proving who the end user is, an ID token can support session creation or sign-in completion. If the caller needs to invoke an API, retrieve data, or trigger a resource action, the application should present an access token and the resource server should validate it as such. That validation usually includes issuer, audience, signature, expiry, scopes or claims, and any tenant or subject constraints.

In practice, the safest pattern is to separate authentication from authorisation. The identity provider authenticates the subject and may issue an ID token to the client. The client then uses an access token to call downstream services. The API must never infer permission from the presence of an authenticated user alone. This distinction becomes especially important in NHI and agentic environments, where autonomous software may chain calls across tools and services. NIST guidance on control validation in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access decisions need explicit enforcement points, not assumptions.

• Use ID tokens for client-side proof of authentication, not API authorisation.
• Use access tokens for resource access, and validate audience and expiry at the resource server.
• Keep token lifetimes short enough to reduce replay risk, especially for NHIs and agents.
• Do not pass ID tokens to APIs unless the provider explicitly documents that pattern, which is uncommon.

NHIMG research shows why this separation matters: token exposure is common, and the 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild. These controls tend to break down in microservice meshes and agentic pipelines because services often validate “a token” without verifying whether it is the right token for that hop.

Common Variations and Edge Cases

Tighter token separation often increases implementation overhead, requiring organisations to balance developer convenience against stricter validation and lifecycle controls. That tradeoff is usually worth it, but there is no universal standard for every architecture yet. Some platforms support hybrid flows, token exchange, or delegated consent models that blur the line between end-user identity and service authority, so security teams need to document which token type is accepted at each boundary.

One common edge case is front-end apps that receive both tokens from an identity provider. Best practice is evolving, but current guidance suggests the ID token should remain inside the client for local session handling, while the access token is forwarded only to the intended resource server. Another edge case appears in NHI-heavy workloads where an agent acts on behalf of a user: the agent may authenticate with its own workload identity while also carrying delegated context. In those cases, the access token authorises the action and the ID token, if used at all, only identifies the subject for the client experience.

Security teams should also watch for overbroad acceptance rules in gateways, especially where multiple token issuers or token types are present. The Ultimate Guide to NHIs and the GitHub Dependabot Breach both illustrate how identity sprawl and token misuse can create access paths that were never intended. Organisations with legacy SSO integrations, mobile clients, or token forwarding proxies are especially likely to need explicit rules because mixed token handling quickly becomes a hidden trust shortcut.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams use IAST and RASP in NHI governance?
• How should security teams govern API keys used for generative AI access?