OAuth is a delegated authorisation protocol that lets one application grant another limited access without sharing the owner’s primary credentials. In practice, its security depends on how tightly scopes are defined and whether the resulting tokens are monitored and revoked when access changes.
Expanded Definition
OAuth is best understood as delegated authorisation, not authentication. It lets a client application obtain limited access to a resource on a user’s or organisation’s behalf, usually through access tokens, refresh tokens, scopes, consent grants, and revocation controls. In NHI and IAM programs, OAuth becomes especially important when software agents, SaaS integrations, and third-party apps act with execution authority but should not inherit the primary credentials of the identity they represent.
Definitions vary across vendors when OAuth is discussed alongside OIDC, but the security boundary is clear: OAuth governs what a token can do, while identity assurance and session context come from other controls. Guidance in the NIST Cybersecurity Framework 2.0 reinforces that access governance must be observable, reviewed, and revoked when business need ends. For NHIs, that means treating every delegated grant as a live credential relationship with its own lifecycle.
The most common misapplication is using OAuth as a proxy for trusted identity, which occurs when teams assume a valid token proves the app should retain broad access indefinitely.
Examples and Use Cases
Implementing OAuth rigorously often introduces consent-management and token-lifecycle overhead, requiring organisations to weigh integration convenience against the operational cost of scope review, monitoring, and revocation.
- A SaaS app connects to a CRM through delegated scopes so it can read leads, but not export billing records or change permissions.
- An AI agent uses a short-lived access token to call internal APIs, with refresh privileges restricted to a narrow broker service.
- A partner integration is approved for ticket creation only, avoiding the common pattern of granting full mailbox or directory access.
- A breach investigation follows token abuse in the style of the Salesloft OAuth token breach, where delegated access becomes the attacker’s foothold.
- Post-incident access review uses vendor and app inventory evidence similar to the visibility concerns described in The State of Non-Human Identity Security.
Because OAuth grants are often embedded in SaaS marketplaces and automation platforms, the practical question is rarely whether delegation is allowed, but whether the scope can be limited, monitored, and removed without breaking the business process.
Why It Matters in NHI Security
OAuth matters in NHI security because it is one of the most common ways machine identities gain durable access to sensitive systems. When a delegated grant is over-scoped, unmonitored, or never revoked, attackers can move laterally through connected apps without ever touching a password. NHIMG 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 turns delegated access into hidden attack surface.
OAuth also intersects with secrets governance, token hygiene, and offboarding discipline. The findings in Ultimate Guide to NHIs show how often organisations fail to rotate or retire long-lived credentials, and similar failure patterns apply when OAuth grants are left active after the original business need has ended. Practitioner teams should align OAuth review with NIST Cybersecurity Framework 2.0 access governance so delegated apps are treated as first-class identities.
Organisations typically encounter OAuth risk only after a vendor compromise, token replay, or suspicious API access reveals that a trusted integration had broader reach than expected, at which point OAuth 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 | OAuth grants often expose tokens and overbroad delegated access. |
| NIST CSF 2.0 | PR.AC-4 | OAuth delegated access must be monitored and limited to least privilege. |
| NIST Zero Trust (SP 800-207) | 4.1 | OAuth fits zero trust when every token is treated as a bounded, verified session. |
Apply continuous verification and narrow policy to each OAuth token grant.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
