An OAuth-connected integration is a third-party application that receives delegated permission to act inside a user or workspace boundary. In NHI governance, it must be treated as a non-human identity with explicit scope, ownership, and review, because compromise of the integration can inherit the access it was granted.
Expanded Definition
OAuth-connected integrations are delegated access paths, not just “apps.” They operate inside a user or workspace boundary with scoped permissions, refresh-token behavior, and policy dependencies that can outlive the initial consent event. In NHI governance, the integration should be treated as an NHI because its access is machine-executed, persistent, and often difficult to distinguish from normal SaaS activity. Definitions vary across vendors on whether the integration, the token set, or the backing service principal is the primary identity object, so teams should anchor controls to the actual access path rather than the label. The most common misapplication is treating consent as a one-time setup task, which occurs when owners never revalidate scopes, connected tenants, or downstream data exposure.
For practical identity governance, this term sits between IAM federation and application risk management. NIST guidance on identity assurance and access control helps frame the lifecycle expectations, but it does not fully resolve how every SaaS vendor models delegated authorization, so operators still need local policy decisions. When an integration can read mail, post messages, or sync records, it has enough authority to become a durable attack path if compromise occurs.
Examples and Use Cases
Implementing OAuth-connected integration oversight rigorously often introduces review overhead and user friction, requiring organisations to weigh convenience and automation against visibility, revocation speed, and blast-radius reduction.
- A sales productivity app receives permission to read CRM records and send messages on behalf of a workspace, so access reviews must cover the integration as a persistent NHI rather than a short-lived user session.
- A support desk connector ingests customer data from email and ticketing systems, creating a cross-domain trust chain that should be validated against NIST Cybersecurity Framework 2.0 functions for identity, monitoring, and governance.
- A file-signature workflow is granted access to documents and contact lists. The Dropbox Sign breach illustrates how delegated app access can become a data exposure event when tokens or scopes are abused.
- A collaboration integration is added by a department without security review, then persists after the original owner leaves. This is where shadow app inventories and consent governance become operationally necessary.
- Security teams investigate unusual API activity and find the attack originated through a compromised third-party OAuth grant, similar to patterns seen in the Salesloft OAuth token breach.
Why It Matters in NHI Security
OAuth-connected integrations are important because they often bypass the controls practitioners expect to protect human accounts. A delegated grant can outlast the employee who approved it, continue syncing data after a role change, and retain high-value scopes that were never revalidated. In The State of Non-Human Identity Security, Astrix Security & CSA found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly these integrations can escape normal governance. That visibility gap matters because attackers do not need to steal a password if they can inherit a trusted token path.
For NHI programs, this means OAuth apps should be inventoried, assigned ownership, reviewed for least privilege, and monitored for anomalous consent or refresh activity. They also belong in Zero Trust policy discussions, because trusted network location does not make delegated access safe. Practitioners should pair that approach with lifecycle controls described in the NIST Cybersecurity Framework 2.0 and with token-focused incident response lessons from the Salesloft OAuth token breach. Organisations typically encounter this risk only after a connected app starts exfiltrating data or impersonating legitimate activity, at which point the OAuth-connected integration 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 apps are NHI-like delegated identities that need scope and lifecycle control. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and identity governance map directly to delegated app permissions. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires verifying each delegated access path, not assuming trust from consent. |
Treat OAuth grants as dynamic access paths and reauthorize them under Zero Trust policy.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
