The industry-standard authorisation framework enabling applications to obtain limited, scoped access to user accounts or services via access tokens, without exposing credentials. The preferred authentication standard for modern NHI integrations.
Expanded Definition
OAuth 2.0 is an authorisation framework, not a password replacement. It lets an application request scoped access to a user’s data or a service’s API through access tokens, refresh tokens, and consent grants. In NHI environments, it often governs how agents, integrations, and third-party apps reach SaaS and internal platforms without handling user credentials directly.
Its core value is delegated access: the app receives only the permissions needed, ideally for a defined time window and a specific resource set. That makes OAuth 2.0 a foundational control for modern identity federation, but it is not a complete security model by itself. Token scope, consent hygiene, rotation, revocation, and logging still determine whether the deployment is safe. Guidance in the industry is still evolving on how strictly OAuth 2.0 should be treated for autonomous agents, so practitioners should avoid assuming a granted token equals trusted workload identity. The most common misapplication is treating broad, long-lived OAuth consent as a harmless integration shortcut, which occurs when teams skip scope minimisation and revocation planning.
For implementation context, align OAuth 2.0 usage with the NIST Cybersecurity Framework 2.0 and treat every token as a bounded credential with a lifecycle, not a static configuration choice.
Examples and Use Cases
Implementing OAuth 2.0 rigorously often introduces consent and token-lifecycle overhead, requiring organisations to weigh user convenience and fast integration against tighter scope control and revocation discipline.
- A sales automation platform connects to email and CRM through scoped OAuth grants instead of storing a shared admin password.
- An AI agent accesses a ticketing system with short-lived tokens and narrowly defined scopes to create or update records only.
- A third-party analytics app requests read-only access to a SaaS workspace, with approval tied to a specific business owner and renewal cycle.
- During incident response, security teams revoke a compromised app’s OAuth consent to cut off access without resetting every user password.
This pattern matters in real breach investigations. The Salesloft OAuth token breach shows how token theft can turn delegated access into direct data exposure, while the Dropbox Sign breach highlights how connected applications can widen blast radius when approvals are not tightly governed. OAuth 2.0 is therefore best understood as a controlled access mechanism that still depends on surrounding identity policy, monitoring, and revocation readiness.
For standards-based implementation thinking, the NIST Cybersecurity Framework 2.0 is useful for mapping authorisation, monitoring, and recovery responsibilities across teams.
Why It Matters in NHI Security
OAuth 2.0 becomes critical the moment non-human identities start accessing business systems at scale. In practice, it is one of the most common ways NHIs gain entry to SaaS, APIs, and collaboration tools, which means weak token governance quickly becomes an attack path. NHI Mgmt Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% only partial visibility. That visibility gap creates a blind spot for overbroad scopes, dormant consents, and shadow integrations.
OAuth problems also tend to combine with broader NHI failures such as excessive privileges, poor rotation, and weak logging. When a token is compromised, the issue is not just authentication, but the inability to prove what the token could reach, how long it remained valid, and whether it was revoked in time. Practitioners should treat OAuth inventories, scope reviews, and consent revocation as routine control activities rather than one-time setup tasks.
Organisations typically encounter OAuth risk only after an integration is abused or a token is stolen, at which point delegated access becomes operationally unavoidable to address.
The governance lens should also align to the NIST Cybersecurity Framework 2.0, especially where access control, monitoring, and recovery need to be coordinated across applications and vendors.
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-03 | OAuth tokens are NHI credentials that can be over-scoped, leaked, or left unrevoked. |
| NIST CSF 2.0 | PR.AA, PR.AC | OAuth 2.0 implements access control and authentication-related identity decisions in connected systems. |
| NIST Zero Trust (SP 800-207) | Section-level | OAuth supports zero trust only when tokens are continuously validated and tightly scoped. |
Inventory OAuth grants, minimise scopes, and revoke tokens when apps, agents, or vendors change.
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
