A short-lived bearer credential issued after successful authorization that allows an application to call APIs on a user's behalf. In NHI governance terms, it is a reusable access artifact whose scope, expiry, and revocation path must be controlled like any other privileged credential.
Expanded Definition
An OAuth access token is the credential an authorization server issues after a user or workload grants consent. It is meant to be short-lived, narrowly scoped, and presented as a bearer token to APIs without re-entering the original login flow.
In NHI governance, that matters because the token is not just a convenience artifact. It is a transferable access right with blast radius defined by scope, audience, and expiry. The industry often treats access tokens as a temporary byproduct of OAuth, but for service accounts, agent workflows, and delegated automation, they function like privileged NHI credentials and should be governed accordingly. Guidance from the OWASP Non-Human Identity Top 10 is especially useful here because it frames token handling as an identity control problem, not only an app integration detail.
Definitions vary across vendors on refresh semantics, token binding, and whether a token should be treated as a session artifact or a standing credential. The most common misapplication is leaving access tokens effective far beyond the intended workflow window, which occurs when teams copy user-centric OAuth patterns into long-running automation without enforcing expiry and revocation.
Examples and Use Cases
Implementing OAuth access tokens rigorously often introduces operational friction, requiring organisations to balance API usability and automation reliability against tighter expiry, rotation, and revocation controls.
- Short-lived API access for a SaaS integration, where the token allows a reporting app to read customer records for one hour and then expires automatically.
- Agent-to-tool access in an AI workflow, where an autonomous software entity calls internal APIs and must be constrained by narrowly scoped, auditable tokens rather than broad user delegation.
- Incident-driven containment after token exposure, such as the Salesloft OAuth token breach, where stolen bearer credentials were used to access downstream data.
- Developer tooling and CI/CD integrations, which can resemble the exposure patterns described in the JetBrains GitHub plugin token exposure case when secrets or tokens are leaked into build systems.
- Federated identity and authorization design, where oauth token complement trust boundaries described by the OWASP Non-Human Identity Top 10 and help limit how far a compromised integration can move.
These use cases are not interchangeable. A token issued for a human session, a background service, and an AI agent may all use OAuth mechanics, but the acceptable lifetime, audience restriction, and monitoring threshold should differ materially.
Why It Matters in NHI Security
OAuth access tokens are often the first credential attackers can reuse after a compromise because they are already authorized and frequently valid outside the original login event. That is why token hygiene sits at the center of NHI security: one exposed token can impersonate an approved integration, bypass MFA, and create lateral movement through trusted APIs. The NHI risk is not theoretical. GitGuardian reports that 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, underscoring how often reusable credentials escape intended control planes.
For governance teams, the practical lesson is to treat access tokens as revocable, observable assets with lifecycle ownership. That means scoping by least privilege, aligning expiry to business need, logging token use, and invalidating tokens when the authorizing context changes. It also means connecting token review to broader NHI programs, as highlighted in the Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge, because the operational failure is usually duplicated credential sprawl, not a single bad token.
Organisations typically encounter the real impact only after a breach, when an otherwise valid token is found in logs, chat, or a code commit and token revocation becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret and token management for non-human identities. |
| NIST CSF 2.0 | PR.AC-1 | Covers identity proofing and access management for authenticated entities. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires continuous authorization checks for bearer credentials. |
Assume token compromise is possible and enforce continuous validation and least privilege.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
