A delegated OAuth flow where a user explicitly approves what an application can access on their behalf. The authorization code flow introduces the resource owner into the trust chain, which means token handling, consent boundaries, and revocation become central governance concerns.
Expanded Definition
3-legged OAuth, more precisely the authorization code flow with user consent, is the delegated access pattern most organisations mean when they say an app can act “on behalf of” a user. It introduces three parties into the trust chain: the user, the client application, and the authorization server. That extra step matters because the client does not receive the user’s credentials, only an authorization code that is exchanged for tokens under controlled conditions.
In NHI and IAM governance, the term is important because it marks the boundary between user consent and machine-to-machine automation. The client may be a web app, desktop app, or integration that needs scoped access to a mailbox, CRM record, or storage account. Standards bodies such as the OAuth 2.0 authorization framework define the flow, but operational usage varies across vendors, especially around refresh token lifetime, consent prompts, and token binding. NHI teams should treat the client as an identity with its own risk posture, not as a neutral conduit.
The most common misapplication is treating 3-legged OAuth as a “safe login shortcut,” which occurs when teams ignore consent scope, token persistence, and third-party app vetting.
Examples and Use Cases
Implementing 3-legged OAuth rigorously often introduces user friction and governance overhead, requiring organisations to weigh seamless delegated access against tighter consent review and token revocation controls.
- A sales rep connects a CRM app to a mailbox and grants read access to calendar and email metadata for scheduling automation.
- A customer support integration uses delegated access to create tickets and retrieve case history without storing a user password.
- A productivity SaaS app requests access to cloud storage on behalf of a user, then keeps refresh tokens for background sync until consent is revoked.
- An enterprise reviews third-party OAuth grants after incidents like the Salesloft OAuth token breach, where delegated tokens became the practical attack path.
- Security teams compare delegated app behavior with guidance from the NIST Cybersecurity Framework 2.0 when mapping access review and incident response responsibilities.
These use cases show why 3-legged OAuth is often chosen for productivity and integration workflows, but the same design can widen exposure if app publishers request broad scopes or keep long-lived tokens. In a real enterprise review, a delegated app should be assessed for business need, consent scope, token handling, and offboarding behavior before approval.
Why It Matters in NHI Security
3-legged OAuth is a major NHI concern because delegated tokens often outlive the human action that created them. When an employee leaves, changes roles, or simply forgets a connected app, the application can retain access through refresh tokens, cached sessions, or poorly governed consent grants. That is why NHI Management Group 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, a visibility gap that makes delegated access hard to inventory and harder to revoke.
Security teams should treat every OAuth grant as a standing trust decision that needs classification, monitoring, and periodic revalidation. This is especially relevant in events like the Dropbox Sign breach, where identity-linked integrations and token paths become part of the blast radius. 3-legged OAuth also fits the broader guidance in NIST Cybersecurity Framework 2.0, particularly around access control and continuous monitoring.
Organisations typically encounter the operational cost of 3-legged OAuth only after a compromised integration, stale consent grant, or token abuse forces emergency revocation, at which point delegated access 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 consent grants and token handling are core non-human identity risks. |
| NIST CSF 2.0 | PR.AA | Addresses identity proofing, authentication, and access governance for delegated access. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous verification of granted access, including delegated tokens. |
Inventory delegated apps, scope grants tightly, and revoke stale OAuth tokens promptly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
