A permission model that lets a user grant an application access to data without sharing a password. In identity governance terms, it shifts risk from credential theft to consent abuse, so the app registration, user role, and authorisation scope all need ongoing review.
Expanded Definition
Delegated OAuth is the consent-based permission model that lets an application act on a user’s behalf without collecting the user’s password. In NHI security, the important distinction is that the app does not become the user; it receives scoped access through an authorisation grant that can be time-bound, revoked, and audited. That makes Delegated OAuth different from app-only access, where an autonomous service or NIST Cybersecurity Framework 2.0-aligned workload identity operates without a human consent event.
Definitions vary across vendors when OAuth is embedded inside SaaS marketplaces, admin consent flows, or device-code interactions, so practitioners should treat the grant, the scope, and the downstream refresh token as separate governance objects. The practical question is not whether an app has access, but what it can reach, who approved it, and how long that approval remains valid. That is why Delegated OAuth sits at the intersection of IAM, NHI governance, and consent risk. The most common misapplication is treating a one-time user approval as permanent trust, which occurs when scopes are never revalidated after the application’s purpose changes.
Examples and Use Cases
Implementing Delegated OAuth rigorously often introduces approval friction and review overhead, requiring organisations to weigh user convenience against the cost of ongoing entitlement governance.
- A productivity app requests mailbox read access for one user, but the security team limits scope to a single folder and schedules periodic review of the consent grant.
- A workflow automation tool uses delegated access to create calendar events, yet the organisation revokes unused scopes after a pilot ends to reduce dormant exposure.
- A third-party analytics app connects through OAuth to a CRM, and security teams monitor for scope drift because the integration may expand from read-only access to data export.
- An AI assistant receives delegated access to documents for drafting summaries, but the organisation pairs it with conditional approval and short-lived refresh token policies.
These patterns matter because OAuth-based integrations are often approved by business users who see the convenience first and the risk later. In the Salesloft OAuth token breach, attackers showed how consented access can become a high-value path into downstream systems when tokens are not tightly governed. For implementation guidance, organisations commonly map these reviews to the identity and access discipline described in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Delegated OAuth is a security boundary, not just a usability feature. Once an application receives consent, it may inherit access to mail, files, tickets, CRM records, or other sensitive systems, making the token and the approved scope part of the organisation’s NHI attack surface. If review processes are weak, consent can outlive the business need, refresh tokens can remain active, and third-party apps can become hidden persistence mechanisms.
This is especially important because NHI exposure is frequently broader than teams realise. NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, which is a strong signal that delegated access and vendor-linked consent must be governed as shared risk. The same risk pattern appears in incidents such as the Dropbox Sign breach, where authentication-adjacent pathways can become operationally significant when permissions are broader than intended. For governance, Delegated OAuth should be reviewed alongside privileged access, app registration control, and Zero Trust controls referenced in NIST Cybersecurity Framework 2.0.
Organisations typically encounter delegated-access abuse only after an unexpected data pull, token theft, or third-party incident, at which point the consent model 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 | Covers secrets, tokens, and lifecycle control for non-human access paths. |
| NIST CSF 2.0 | PR.AA-1 | Addresses identity proofing, credential use, and access authorization governance. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust emphasizes continuous verification and least-privilege enforcement for access paths. |
Review OAuth grants, token exposure, and app registrations as NHI assets with lifecycle controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
