An OAuth connected app is a third-party integration that uses approved scopes and tokens to act inside another system. For security teams, it functions like a non-human identity with persistent access and therefore needs ownership, review, and offboarding controls. Compromise of the token often becomes compromise of the trust relationship.
Expanded Definition
An OAuth connected app is more than a convenience layer between systems. It is an authorization relationship that lets one application act with the privileges granted by a user, admin, or service owner, usually through scoped tokens and consented access. In NHI practice, that makes the app function like a persistent non-human identity with its own trust boundary, lifecycle, and offboarding requirements. The language around connected apps varies across vendors, but the security problem is consistent: once a token is issued, the app can continue operating until access is revoked, scopes are reduced, or the token expires. That is why governance must cover ownership, approved scopes, monitoring, and retirement. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it ties identity governance to ongoing protection and recovery, not just initial approval. The most common misapplication is treating a connected app as a one-time admin setting, which occurs when teams approve OAuth access without assigning an owner or review cadence.
Examples and Use Cases
Implementing OAuth connected app governance rigorously often introduces friction in onboarding and support, requiring organisations to weigh fast integration against the cost of continuous review and revocation discipline.
- A CRM integration uses delegated scopes to sync contacts and activity into a marketing platform, and the security team records the app owner, permitted data types, and renewal date.
- A productivity tool connects to a storage platform for file indexing, but the organisation limits scope to read-only access and logs token usage for anomaly detection.
- An internal automation tool posts tickets into an ITSM system using a service-issued token, and access is rotated when the workflow owner changes or the tool is retired.
- After the Salesloft OAuth token breach, defenders had to treat the token-bearing app as an active identity path, not just an integration record.
- In the Dropbox Sign breach, third-party connectivity illustrated how connected applications can widen exposure when trust is not continuously validated.
These patterns align with the identity-first framing used in zero trust and vendor access governance, where connected applications are evaluated for privilege, telemetry, and offboarding readiness rather than convenience alone.
Why It Matters in NHI Security
OAuth connected apps matter because they are a common place where trust outlives oversight. An approved integration can keep access long after the business process changes, the vendor relationship ends, or the original approver leaves. That gap is especially dangerous in NHI environments because the app often holds broad delegated power across email, files, CRM data, ticketing systems, or APIs. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means many teams cannot confidently answer who has access, why it exists, or when it was last reviewed. This is where IAM, PAM, and lifecycle control converge: connected apps need the same discipline as any other persistent identity, including owner assignment, scope minimisation, revocation paths, and post-incident inspection. In practice, this maps to least privilege, continuous verification, and breach containment. Organisations typically encounter the operational reality of OAuth connected apps only after a token is abused or an integration is no longer trusted, at which point revocation and revalidation become unavoidable.
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 secret and token governance for non-human identities like connected apps. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access permissions and least-privilege control for shared or delegated access. |
| NIST Zero Trust (SP 800-207) | null | Zero trust requires continuous verification of every application trust relationship. |
Review OAuth grants regularly and remove any scope that is not required for the business task.
