What is the difference between delegated access and application access in OAuth governance?

Delegated access acts on behalf of a signed-in user and is bounded by that user’s entitlements, while application access is direct app-to-resource access with broader organisational reach. Governance must distinguish them because delegated permissions still create durable machine access paths that require lifecycle review and revocation.

Why This Matters for Security Teams

delegated access and application access often look similar in an OAuth console, but they create very different governance obligations. Delegated access inherits a user’s scope, session context, and revocation path, while application access can persist independently of any human login. That distinction matters because both patterns still create durable machine access paths, which fall squarely into NHI governance. NHI programmes that only review user accounts miss token sprawl, third-party integrations, and silent privilege drift.

NHIMG research shows why this is not theoretical: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security by Astrix Security & CSA. That visibility gap is exactly where delegated grants become long-lived operational risk, especially when they are never re-approved after the original business use case changes. Governance should therefore treat OAuth grants as living non-human identities, not just authentication artefacts. Current guidance from NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 both points toward continuous access oversight, not one-time approval.

In practice, many security teams discover the difference only after an OAuth app has already retained access long after the initiating user stopped needing it.

How It Works in Practice

Delegated access is designed to act on behalf of a signed-in user. The app receives tokens that reflect user consent and should be limited by the user’s role, group membership, and the scopes approved at consent time. Application access, by contrast, is app-to-resource access: no user session is required, so the organisation must govern the app as a standing workload identity with its own lifecycle, owner, and revocation path.

In operational terms, security teams should separate the review workflow for each pattern:

• For delegated grants, confirm the business purpose, approved scopes, and the user population that can trigger the grant.
• For application access, verify the service owner, secret storage, token rotation, and whether the app still needs direct access.
• For both, track where tokens are used, who approved them, and how they are revoked when the relationship ends.

This is where OAuth governance overlaps with NHI lifecycle management. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the Top 10 NHI Issues both reinforce the same pattern: consent is not a control by itself. A delegated token can remain active even when the user no longer needs the integration, and application access can outlive the project that created it. That is why lifecycle review, revocation testing, and scope minimisation belong in the same control set as access approvals. Teams that ignore this distinction also miss breach patterns such as the Salesloft OAuth token breach, where OAuth credentials became a durable access path.

These controls tend to break down in SaaS-heavy environments with many third-party integrations because ownership, scopes, and revocation responsibility are spread across multiple teams.

Common Variations and Edge Cases

Tighter OAuth governance often increases operational overhead, requiring organisations to balance developer productivity against revocation discipline. That tradeoff is real, especially when delegated access is used for automation, service desks, or workflow tools that blur the line between user action and machine action.

Some environments treat “delegated” as low risk because it inherits human permissions, but that assumption is incomplete. A delegated app can still request broad scopes, access shared mailboxes, read files across collaboration spaces, or create onward automations that persist after the user stops interacting. Application access has a different edge case: some vendors expose token-based service accounts that look like app-only access but are actually tied to hidden human ownership or undocumented admin consent. Best practice is evolving here, and there is no universal standard for consent revalidation intervals yet, but current guidance suggests tying review cadence to data sensitivity, scope breadth, and whether the integration crosses tenants or business units.

For audit and control design, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for framing evidence collection, while Dropbox Sign breach illustrates how third-party access can become a hidden dependency. Practitioners should also align OAuth governance with NIST Cybersecurity Framework 2.0 and document the distinction in control language, so delegated consent does not get mistaken for a one-time business exception.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between human IAM controls and NHI governance?