A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
Expanded Definition
An OAuth token is a delegated credential that lets a non-human identity access a defined resource set without revealing long-term secrets. In NHI security, the token is valuable because it narrows exposure through scope, audience, and expiry, but only if issuance, storage, and revocation are managed correctly.
The term is often used loosely alongside access tokens, bearer tokens, refresh tokens, and session tokens, yet those are not interchangeable. Definitions vary across vendors, and no single standard governs every implementation detail, but OAuth 2.0 remains the common baseline. The practical security meaning is simple: an OAuth token should represent least-privilege access for a short duration, not a standing credential that can be reused indefinitely. NIST’s NIST Cybersecurity Framework 2.0 reinforces this logic through identity, access control, and continuous monitoring outcomes.
The most common misapplication is treating an OAuth token like a durable API key, which occurs when teams store it in code, tickets, or shared chat without automated expiry and revocation.
Examples and Use Cases
Implementing OAuth token handling rigorously often introduces operational friction, requiring organisations to balance developer convenience against tighter revocation, rotation, and audit requirements.
- An integration between a SaaS platform and a data warehouse uses scoped OAuth tokens so the NHI can read only one dataset instead of inheriting broad account access.
- A CI/CD runner exchanges a workload identity for a short-lived token before publishing artifacts, reducing the blast radius if the runner is compromised. This pattern is central to the guidance in Guide to the Secret Sprawl Challenge.
- A third-party app is granted a token for mailbox read access, then the organisation limits the grant to a narrow scope and an explicit expiry to satisfy NIST Cybersecurity Framework 2.0 access-control expectations.
- After a vendor compromise, investigators invalidate token grants tied to the affected app rather than resetting every password, as seen in cases like the Salesloft OAuth token breach.
- An AI agent requests a token for a single API workflow, then a policy engine denies any attempt to reuse it outside that approved service boundary.
Why It Matters in NHI Security
OAuth tokens matter because they are frequently the bridge between identity and data access in modern NHI architectures. If the token is exposed, duplicated, or left active after the workload or employee is gone, the organisation has a live credential problem, not just a detection problem. That is why the issue shows up so often in breach analysis and secrets-sprawl research, including the Guide to the Secret Sprawl Challenge and incidents such as the Dropbox Sign breach.
GitGuardian found that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why short-lived design only works when revocation is automatic and reliable. OAuth tokens also align directly with NHI governance concerns: scope drift, overused identities, duplicated storage, and offboarding failures. In practice, a token that remains in Jira, Slack, Confluence, or a code commit is still an operational access path, even if the original app is no longer trusted.
Organisations typically encounter the real cost of an OAuth token only after a compromise, at which point token tracing, revocation, and scope review become 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 | Covers improper secret handling and token exposure in NHI environments. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access and managed credential use for workloads. |
| NIST Zero Trust (SP 800-207) | Section 3.2 | Zero Trust requires per-request verification rather than trusting standing credentials. |
Treat each token as conditional access and revalidate trust before every sensitive transaction.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
