A non-human identity created when a third-party application is granted OAuth access to enterprise systems. It is not a person, but it can act with delegated authority, persist over time, and reach sensitive data if the scope is broad or the integration is poorly governed.
Expanded Definition
An OAuth-connected NHI is an application identity created when a third-party app receives delegated access through OAuth scopes. It can authenticate repeatedly, persist beyond a user session, and act across systems with the authority granted by the original consent.
In practice, this makes the identity closer to a long-lived machine principal than a one-time login. The OAuth grant can represent broad read, write, or offline access, so the real security boundary is not the app name alone but the exact scopes, token lifetime, refresh behavior, and revocation path. Definitions vary across vendors when these identities are grouped with service accounts, app registrations, or delegated tokens, so operators should treat the pattern as an NHI governance issue rather than a narrow IAM label. NIST Cybersecurity Framework 2.0 is useful here because it reinforces asset visibility, access control, and continuous monitoring as operational requirements, even when the identity is not human. The most common misapplication is treating a delegated OAuth grant as temporary user consent when it has actually become a durable, over-privileged enterprise identity.
For deeper NHI context, see the Ultimate Guide to NHIs and the companion explanation of Ultimate Guide to NHIs — What are Non-Human Identities.
Examples and Use Cases
Implementing OAuth-connected NHI governance rigorously often introduces friction during app onboarding and consent review, requiring organisations to weigh integration speed against scope minimisation and revocation discipline.
- A sales productivity app requests mailbox and CRM access to sync records, then continues operating after the original user leaves. This is a classic delegated identity problem, because the grant survives the person who approved it.
- An AI assistant connects to collaboration tools through OAuth and can read messages, create tasks, and post updates. Here the identity is an NIST Cybersecurity Framework 2.0 concern as much as an application feature, because access needs continuous review.
- A partner integration uses offline refresh tokens to maintain automation without re-prompting users. If the token is stolen, the attacker inherits persistent access until the grant is revoked or expires.
- A security team discovers several third-party apps linked to finance and support systems with broad scopes and no owner. This pattern appears often in the Top 10 NHI Issues because inventory gaps hide who can still act.
- A customer support integration is approved for a single workflow but later inherits additional permissions after an API upgrade. The control failure is not the integration itself, but unmanaged scope drift.
These examples show why OAuth-connected NHIs must be reviewed as living identities, not static app settings.
Why It Matters in NHI Security
OAuth-connected NHIs matter because they combine delegated authority with persistence, which creates a fast path from convenience to compromise when visibility is weak. NHI research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% only partial visibility in The State of Non-Human Identity Security. That gap is especially dangerous when scopes are broader than the business task requires, when offboarding is incomplete, or when refresh tokens are never rotated.
OAuth-connected NHIs also show up in public breach narratives when app trust is abused or tokens are stolen. The Salesloft OAuth token breach and the Cisco DevHub NHI breach both illustrate how delegated access can become an enterprise-wide exposure if governance lags behind integration growth. The right response is inventory, scope review, ownership assignment, and fast revocation paths aligned to least privilege and Zero Trust principles. Organisiations typically encounter this identity only after a token leak, an unauthorized API call, or a vendor incident, at which point the OAuth-connected NHI 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 are long-lived machine identities and fit secret and token governance controls. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access governance applies directly to app-consent based identities. |
| NIST Zero Trust (SP 800-207) | VA-3 | Zero Trust relies on continuous verification of non-human access and authorization context. |
Track delegated OAuth apps, scope them tightly, and revoke unused or risky grants quickly.
