TL;DR: OAuth connections create delegated, token-based access that can outlive user sessions, bypass repeated MFA checks, and accumulate excessive permissions across SaaS tools, according to Astrix Security. The governance problem is not OAuth itself but the unmanaged NHI layer it creates, where visibility, ownership, and lifecycle controls determine whether access remains defensible.
At a glance
What this is: Astrix Security’s analysis explains how OAuth approvals create persistent delegated access that can remain active long after the original user login, with token lifecycle and scope sprawl turning SaaS integrations into hidden access paths.
Why it matters: IAM and security teams need to govern OAuth as a non-human identity problem because token ownership, revocation, and review determine whether integrations remain bounded or become durable access channels.
Context
OAuth is a delegated authorization model, not just a login flow. In practice, it lets a third-party application act on a user’s behalf through tokens and scopes, which means the access relationship can persist independently of the user session that created it.
That creates an identity governance gap for SaaS environments: the application becomes a non-human identity with its own access lifecycle, yet many organisations still manage it as if it were a one-time consent event. The result is hidden access, unclear ownership, and permissions that outlive their business purpose.
Key questions
Q: What breaks when OAuth access is not governed like a non-human identity?
A: Access persists beyond the user session that created it, so the organisation loses the usual sign-in checkpoints that would normally bound use. The application keeps operating with the originally granted token, which means revocation, ownership, and review become the real control points. Without them, integrations turn into standing access paths rather than temporary permissions.
Q: Why do OAuth tokens create risk even after the user logs out or leaves?
A: Because the token is the credential the application uses, not the user’s login session. If the token remains valid, the connected app can keep accessing systems until it is explicitly revoked or expires. That is why password changes or employee departure do not automatically eliminate the access path.
Q: What are the signs that OAuth permissions are drifting out of control?
A: Look for integrations with broad scopes, unused apps that still hold active tokens, unclear ownership, and access patterns that do not match the original business case. Those signals usually mean the integration has become a dormant or over-privileged access path that needs review before it turns into an incident.
Q: How should security teams govern OAuth tokens in SaaS environments?
A: Security teams should treat OAuth tokens as standing access that must be inventoried, reviewed, monitored, and revoked like any other identity credential. The practical model is continuous governance, not one-time approval, because consented apps can keep accessing data long after the user stops thinking about them. Review scopes, owners, and behavior together.
Technical breakdown
Why OAuth tokens behave like non-human credentials
OAuth access and refresh tokens are credentials, not passwords, and they are used by applications to call APIs after the user has already approved access. Once issued, the token can operate outside repeated MFA checks and can persist according to how the integration and revocation logic are implemented. That makes the application itself a governed identity subject, even though many teams still treat it as a convenience layer rather than an access-bearing actor.
Practical implication: inventory OAuth-connected applications as identities with their own lifecycle, not as passive configuration objects.
How scope overreach turns consent into privilege creep
OAuth scopes define what an application can do, but many integrations request more access than the function requires. Because consent is often granted quickly and reviewed rarely, the granted scope set can expand operationally even when the original use case has not changed. This is privilege creep in an NHI form: permissions become broader than the business need, and the mismatch is hard to see until an incident or audit forces review.
Practical implication: compare granted scopes to actual use and remove permissions that are broader than the integration’s current job.
Why third-party app compromise becomes an enterprise access problem
OAuth transfers trust to the connected application, so if that application is compromised, the attacker can inherit the permissions already approved by customers. The risk is not breaking OAuth itself; it is abusing valid delegated access that remains trusted by the target environment. That is why SaaS compromise, token theft, and integration abuse often produce silent exposure instead of obvious login events.
Practical implication: treat third-party OAuth access as a supply-chain and NHI risk, with monitoring focused on token use and abnormal application behaviour.
Threat narrative
Attacker objective: The attacker’s objective is to exploit valid delegated access to reach SaaS data and systems without triggering repeated authentication controls.
- Entry occurs when a user approves a third-party application and the platform issues an OAuth token with delegated access.
- The attacker or malicious application reuses that token to access connected APIs without needing the original user to re-authenticate.
- Excessive scopes and weak lifecycle controls allow the same access path to persist after role changes, offboarding, or vendor compromise.
- Impact comes from silent data access, record modification, or lateral movement across SaaS environments using trusted integration paths.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OAuth has become an unmanaged non-human identity layer in many SaaS environments: The issue is not the authorization protocol itself but the identity estate it creates after consent. Once an application holds a valid token, it becomes an access-bearing actor with ownership, scope, and revocation requirements that many IAM programmes do not track consistently. The practical conclusion is that OAuth must be governed as NHI lifecycle, not treated as a one-time integration setting.
Persistent delegated access creates governance debt that compounds over time: The article describes the familiar pattern of stale permissions, dormant integrations, and unclear ownership. That is a lifecycle failure, not a login failure, and it is why access reviews often miss the real risk. Teams that only govern human sign-in controls will leave application-level access paths untouched.
Hidden access paths are the security outcome of consent without lifecycle control: OAuth approvals often begin as legitimate business enablement and end as unreviewed standing access. That creates a control gap between approval time and revocation time where business context has changed but access has not. Practitioners should recognise this as an identity governance problem spanning user, application, and vendor relationships.
Ownership drift is the named concept that best captures the risk here: The application may still be active long after the approving user has changed roles or left the organisation, so nobody can confidently say who is accountable for the token. That breaks standard governance assumptions about review, recertification, and offboarding. The implication is that ownership must be explicit for every OAuth connection, or the access will outlive the decision that created it.
From our research library:
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
What this signals
Ownership drift is the hidden failure mode in OAuth governance: once consent is granted, the approving user, the application owner, and the SaaS administrator can all assume someone else is responsible. That breaks the accountability chain and leaves delegated access active long after the original business need has changed.
OAuth reviews should move from a login-centric model to a lifecycle model. The practical question is not whether the user authenticated, but whether the connected application still needs the scopes it holds and whether anyone can revoke it quickly when that changes.
For practitioners
- Map all OAuth-connected applications Build an inventory of every connected application, the scopes it holds, the token type in use, and the business owner responsible for revocation decisions.
- Review scopes against actual use Compare granted permissions to the integration’s real function and remove read-write or broad object access where the workflow only needs a narrow subset.
- Assign explicit token ownership Tie each integration to a named owner who is accountable for approval, periodic review, and removal when the business need ends.
- Monitor for abnormal token behaviour Track unusual API calls, dormant integrations that wake up, and access patterns that do not match the original use case or expected service behaviour.
- Revoke dormant delegated access Remove tokens and connected apps that are no longer required, especially when the approving user changes role, leaves, or the vendor relationship changes.
Key takeaways
- OAuth creates a delegated access layer that can persist independently of the user’s login session, which makes it an identity governance problem as much as an authentication one.
- The main operational risk is scope creep and ownership drift, not the protocol itself. Hidden integrations become dangerous when nobody can explain why they still exist or who can remove them.
- The most effective control is lifecycle governance over connected applications, including explicit ownership, scope review, and token revocation when the business need ends.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | OAuth tokens are credentials that can persist and expose access when poorly governed. |
| NHI-05 — Overprivileged NHI | The article highlights broad scopes and permission creep across connected applications. | |
| NHI-07 — Long-Lived Secrets | Persistent OAuth tokens can remain valid beyond user changes and session boundaries. | |
| Recommendation — Inventory OAuth tokens as secrets and revoke any exposed or orphaned credentials immediately. Review granted OAuth scopes against actual use and trim access to the minimum required. Set explicit expiry and revocation rules for OAuth tokens that outlive their business purpose. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | OAuth governance is fundamentally about controlling permissions and authorisations over time. |
| Recommendation — Apply entitlement reviews to connected applications and remove stale OAuth grants. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens function as authenticators that require lifecycle management and revocation. |
| Recommendation — Manage OAuth tokens under IA-5 so issuance, rotation, and revocation are governed consistently. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Token abuse enables access to data paths and can lead directly to theft of SaaS data. |
| Recommendation — Map OAuth abuse to credential access and exfiltration to prioritise monitoring for token misuse. | ||
Key terms
- OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Scope: Scope is the explicit boundary of what testers are allowed to examine in a security programme. It defines the assets, environments, and techniques that are in bounds and out of bounds, helping prevent irrelevant reports, accidental disruption, and uncontrolled testing of sensitive systems.
- Ownership Drift: Ownership drift occurs when the person or team recorded as responsible for an NHI no longer matches operational reality. It often appears after reorganisations, platform migrations, or inherited service accounts. Drift weakens response, rotation, and certification because the governance record no longer points to the right decision-maker.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org