OAuth integrations can leave behind refresh tokens that continue to work if the underlying application or project state is not fully and correctly invalidated. That creates a gap between what users see and what attackers can still use. The risk is highest when users have granted broad scopes, because a hidden token can keep exposing mail, files, calendars, or cloud services.
Why This Matters for Security Teams
Deleted apps often create a false sense of closure because OAuth consent is not the same as continuous control. If a refresh token survives, an attacker or former vendor can keep exchanging it for new access long after the interface has disappeared. That is why third-party integrations are a persistent NHI problem, not just an application cleanup issue. The risk grows sharply when scopes are broad and monitoring is weak, as shown in The State of Non-Human Identity Security.
Practitioners also underestimate how often hidden OAuth access is tied to supply-chain compromise. The Salesloft OAuth token breach and Microsoft OAuth Breach show that token abuse can persist beyond what administrators believe they have removed. Current guidance from the OWASP Non-Human Identity Top 10 treats these integrations as privileged machine identities that need lifecycle control, not one-time app approvals. In practice, many security teams discover the lingering token only after data access has already continued unnoticed.
How It Works in Practice
OAuth risk persists because the visible application object, the consent grant, and the actual credential are separate things. Deleting an app in a console may remove the listing, but it may not automatically revoke refresh tokens issued to that app. Those tokens can keep minting access tokens until they expire, are explicitly revoked, or are invalidated by a provider-side event. This is why lifecycle hygiene for OAuth should be treated like NHI governance, not simple software uninstall.
Effective response usually starts with inventory, then moves to revocation and scope reduction. Security teams should identify every connected app, map which users and service accounts consented, and verify whether refresh-token invalidation is enforced at deletion. Then they should look for broad scopes such as mail, files, directory, calendar, and cloud admin permissions. The operational question is not just “is the app gone?” but “can any credential still act on its behalf?” That aligns with both The 2024 ESG Report: Managing Non-Human Identities and NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls.
- Revoke refresh tokens when an app is removed, not only when it becomes inactive.
- Restrict consent to least-privilege scopes and block high-risk grants by default.
- Continuously monitor OAuth app usage, token refresh events, and unusual API calls.
- Review vendor and employee-owned third-party apps separately, since ownership and accountability differ.
These controls tend to break down in large SaaS estates with inconsistent tenant settings because token state is distributed across providers, directories, and user consent paths.
Common Variations and Edge Cases
Tighter OAuth governance often increases admin overhead, requiring organisations to balance user agility against revocation certainty. That tradeoff is real, especially when business units depend on quick app onboarding or shadow IT tools. Current guidance suggests treating “deleted” and “revoked” as different states, but there is no universal standard for how every provider must implement invalidation.
Edge cases include delegated admin consent, multi-tenant apps, service accounts that outlive the user who approved them, and apps whose permissions were cloned into related environments. In some platforms, removing a user leaves the org-wide consent intact. In others, tokens survive until a separate API call or security event clears them. The best practice is to test deletion workflows in each major SaaS environment and confirm whether access really dies. NHIMG case research such as the Klue OAuth Supply Chain Breach shows why this matters when third-party access is used at scale.
Teams should also assume that an “app appears deleted” event may only reflect UI state, not credential state. That distinction becomes critical during incident response, merger cleanup, and vendor offboarding. Where provider behaviour is unclear, security teams should validate with logs, API queries, and direct token revocation rather than trusting the console view alone. For broader incident patterns, see the 52 NHI Breaches Analysis.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | OAuth tokens are non-human credentials that must be rotated and revoked. |
| OWASP Agentic AI Top 10 | A-02 | Persistent token use mirrors autonomous access abuse and hidden privilege. |
| CSA MAESTRO | I-2 | Covers identity lifecycle and authorization for machine-to-machine access. |
| NIST AI RMF | AI RMF governance helps manage lifecycle risk from autonomous integrations. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access control apply to third-party connected apps. |
Document ownership, monitoring, and remediation for every high-risk OAuth connection.
Related resources from NHI Mgmt Group
- Why do OAuth applications create persistent access risk even after off-boarding?
- Why do third-party identities create persistent breach risk even after onboarding controls are in place?
- Why do OAuth tokens and SaaS integrations create outsized breach risk in connected environments?
- Why do legacy NTLMv1 authentications still create lateral movement risk even after organizations try to disable them?
