OAuth security risks create persistent access beyond user logins

At a glance

What this is: This analysis shows that OAuth risk is really a non-human identity governance problem, because approved applications can retain persistent, over-permissioned access long after the user has moved on.

Why it matters: IAM and NHI teams need to treat OAuth grants as living credentials, not one-time approvals, or hidden third-party access will evade normal access review and offboarding processes.

👉 Read Astrix Security's analysis of OAuth security risks and hidden access paths

Context

OAuth is a delegated access model, not just a sign-in method. The security gap appears after approval, when an application holds tokens that can continue acting on behalf of a user, even as passwords change, roles shift, or the original approver leaves. For NHI governance, that means the control problem is lifecycle management, not authentication alone.

The article maps a familiar enterprise pattern: convenience creates invisible persistence. That is typical in modern SaaS environments, where integrations multiply faster than review processes and ownership records. The result is an access layer that often sits outside the same visibility and offboarding discipline applied to human identities.

Key questions

Q: How should security teams govern OAuth-connected applications as non-human identities?

A: Treat each OAuth grant as a credentialed identity with an owner, purpose, scope, and expiry review. Record who approved it, what it can access, and when it should be revalidated or revoked. That approach closes the gap between SaaS convenience and NHI governance.

Q: Why are OAuth tokens risky even when MFA is enforced for users?

A: MFA protects the user login, but OAuth tokens can keep working after the initial approval without repeated user authentication. If the token is long-lived or refreshable, access may persist independently of the user’s password changes, role changes, or departure from the organisation.

Q: What is the difference between OAuth access and traditional password-based access?

A: Password-based access depends on a human authenticating each time, while OAuth grants delegated access to an application through tokens. That means the security problem moves from login protection to token governance, scope control, monitoring, and revocation across the integration lifecycle.

Q: When should organisations revoke OAuth grants or refresh tokens?

A: Revoke them when the application is no longer needed, ownership changes, the user leaves, the business purpose ends, or the granted scopes no longer match the task. If a connection is dormant, broad, or undocumented, it should be treated as a candidate for removal.

Technical breakdown

How OAuth tokens become non-human identity credentials

OAuth issues access tokens and, often, refresh tokens after user consent. Those credentials let an application call APIs without repeating the original login flow. In practice, the application becomes a non-human identity because it can act independently, reuse authorization, and continue operating until the token is revoked or expires. The security risk is not the protocol itself, but the delegation model: trust is transferred from the human to the application, then preserved in software. If the integration stores tokens poorly, broadens scopes, or lacks revocation discipline, the access path remains active far longer than the business expects.

Practical implication: Inventory OAuth-connected applications as NHI assets and tie each grant to a named owner, purpose, and expiry review.

Why persistent tokens and scope creep widen attack paths

Persistent tokens are dangerous because they can survive the user lifecycle. If a user changes roles or leaves, the application may still hold usable credentials. Scope creep compounds that risk when an app requests read-write or tenant-wide permissions for a narrow task. That turns delegated access into durable privilege, especially when refresh tokens automatically renew access in the background. The attack surface expands further if the application backend is compromised, because stored tokens can be reused against customer environments without needing the user's password or a new consent event.

Practical implication: Limit scopes to the smallest workable permission set and require periodic re-approval for high-risk OAuth grants.

Visibility and ownership gaps in SaaS integrations

OAuth risk becomes hard to manage when organisations cannot see which apps are connected, which scopes were granted, or who owns the integration. This is a governance failure as much as a technical one, because dormant connections often remain active after the business need disappears. The absence of an authoritative inventory also blocks detection and revocation. In NHI terms, the integration is a machine identity with a lifecycle, but many enterprises never assign it one. That leaves security teams reacting only after an incident or audit surfaces the exposure.

Practical implication: Build a continuous review process for connected apps, and reconcile OAuth grants against business ownership and access need.

Threat narrative

Attacker objective: Use trusted delegated access to move through SaaS environments without triggering normal login-based controls.

1. Entry via a third-party application that receives delegated OAuth consent and stores usable tokens.
2. Escalation when overbroad scopes let the application access more data and functions than the original task required.
3. Impact when a compromised application backend or stolen token is reused to extract data or modify records without fresh user authentication.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 consent has become an unmanaged NHI issuance event. When a user approves an app, the organisation is effectively creating a non-human identity with delegated authority, yet many governance programmes still treat that moment as a one-time login. That mismatch is why OAuth grants so often escape access review, offboarding, and ownership tracking. Practitioners should govern approval as credential issuance, not as a routine UI click.

Persistent OAuth access creates trust debt. Refresh tokens, dormant integrations, and overbroad scopes all extend the life of access beyond the original business need. Over time, the environment accumulates hidden permissions that are hard to justify and harder to remove. The practical lesson is simple: if a token can outlive the user, it must be governed like any other long-lived secret.

Identity sprawl now includes third-party SaaS connections. OAuth expands the attack surface without adding an obvious new account to the directory, which is why traditional inventory methods miss it. The result is a governance gap between what IAM thinks is active and what the SaaS layer is actually authorised to do. Security teams should assume this blind spot exists until continuous discovery proves otherwise.

OAuth risk is a Zero Trust problem, not just an application risk. Zero Trust depends on continuous verification, least privilege, and explicit ownership, but delegated tokens often bypass the human-centric controls organisations rely on. When the access decision lives in a token rather than a session, the burden shifts to lifecycle monitoring, revocation, and scope discipline. Teams that want defensible Zero Trust posture must include OAuth grants in the same control plane as other NHI credentials.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For related context: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to The 52 NHI Breaches Report.

What this signals

Ephemeral access is only as safe as the revocation workflow behind it. With 91.6% of secrets still valid five days after notification, the operational problem is not detection alone but the speed at which teams can actually remove access. For OAuth-heavy estates, that means lifecycle controls must be measured in hours and days, not audit cycles.

Hidden SaaS integrations create identity drift across the control plane. As connected apps accumulate, the organisation can no longer assume its directory reflects the real access surface. Teams should align SaaS discovery with NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 so OAuth grants are visible, owned, and reviewable.

OAuth governance now belongs in the same programme as other NHI controls. The practical shift is to treat tokens, scopes, and third-party app approvals as part of a unified non-human identity lifecycle. That gives IAM teams a way to connect privilege management, monitoring, and offboarding across human and machine access paths.

For practitioners

• Discover and classify all OAuth-connected applications Build a live inventory of connected apps, granted scopes, token types, and business owners. Reconcile that list against SaaS tenants and identity records so hidden integrations do not stay outside review. 52 NHI Breaches Analysis can help frame what mismanaged non-human access looks like in practice.
• Reduce permission scope at approval time Require read-only or object-specific scopes unless a broader grant is formally justified. Review high-risk approvals for tenant-wide access, admin-level scopes, and refresh-token use before they are accepted.
• Tie OAuth grants to lifecycle controls Set review and expiry checkpoints for every integration, especially dormant ones. Revoke connections when ownership changes, the app is no longer needed, or the business purpose has ended. The Ultimate Guide to NHIs is a useful reference for lifecycle and revocation discipline.
• Monitor token use for abnormal behaviour Alert on unusual API volume, new geographies, atypical data access, and reuse patterns that do not match the approved application profile. Behaviour monitoring should be part of the same control set as rotation and access review.

Key takeaways

• OAuth creates delegated machine access, so the real control problem is token governance, not login protection.
• Long-lived tokens, broad scopes, and weak ownership create a persistent access layer that traditional IAM reviews often miss.
• Security teams should inventory, constrain, monitor, and revoke OAuth grants with the same discipline used for other non-human identities.

Key terms

• OAuth Token Persistence: OAuth token persistence is the tendency for delegated access to remain usable after the original user action is over. In practice, refresh tokens and long-lived access tokens can keep an application connected until someone revokes them, which makes lifecycle control central to security.
• Consent Fatigue: Consent fatigue happens when users approve application access quickly without understanding the permissions they are granting. In SaaS environments, repeated prompts and workflow pressure can normalise broad delegation, which shifts security risk from authentication to unchecked authorisation.
• Identity Drift: Identity drift is the gap between what an organisation believes is authorised and what is actually still connected. For OAuth and other NHI connections, drift appears when apps remain active after ownership changes, business need ends, or permissions expand beyond the original approval.

What's in the full article

Astrix Security's full article covers the operational detail this post intentionally leaves for the source:

• Concrete OAuth risk examples across Google Workspace, Salesforce, GitHub, and other SaaS platforms
• Step-by-step explanation of how token persistence and refresh behavior can extend access
• Detailed discussion of Ghost Token in Google Cloud Platform and why token lifecycle controls matter
• Practical guidance on visibility, monitoring, permission alignment, and revocation decisions

👉 Astrix Security's full post covers token persistence, scope creep, and the Ghost Token example in more detail

Deepen your knowledge

OAuth governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring SaaS integrations, tokens, and delegated access under control, it is worth exploring.