The Hidden Risk in SaaS-to-SaaS Integrations: Why OAuth Scopes Are Rarely Reviewed

Every time an employee clicks "Allow" to connect a new app to Slack, Google Workspace, or Salesforce, that app receives a set of permissions it keeps indefinitely, until someone manually revokes them. In practice, almost nobody does. The result is an invisible layer of third-party access sitting quietly inside every modern SaaS stack, granted once, reviewed never, and rarely considered part of the organization's actual attack surface.

This is the OAuth scope problem, and it has become one of the more overlooked risks in enterprise software integration.

Why OAuth made this both easier and riskier

OAuth was designed to solve a real problem: letting a user grant a third-party app limited access to their data without handing over a password. In principle, scopes are supposed to enforce the principle of least privilege, an app that only needs to read a calendar shouldn't be able to send emails on the user's behalf.

In practice, the incentive structure works against granularity. Developers request broad scopes because it's simpler to build against, and users approve them because the consent screen appears once, briefly, before the tool they actually want to use. Very few organizations have a process that revisits that decision six months later when the integration is no longer actively used, or when the vendor's own security posture has changed.

The result is a long tail of forgotten integrations holding onto permissions like full mailbox access, file storage read/write, or admin-level API scopes, connected to a tool that half the team stopped using a year ago.

Why this matters more than it looks like it should

A compromised third-party integration doesn't need to breach your network. It already has a standing, authenticated connection into your SaaS environment, and that connection typically isn't monitored the way internal user accounts are. Security teams spend considerable effort on employee account takeover, credential stuffing, and phishing, but an over-permissioned OAuth token sitting with a vendor that gets breached bypasses all of that defense entirely. The attacker doesn't need your employee's password. They already have a live, valid, often unmonitored token.

This is exactly the mechanism behind several supply-chain-style incidents in recent years, where attackers compromised a smaller connected vendor and used its existing OAuth grants to pivot into much larger customer environments, not through a vulnerability in the customer's own systems, but through a permission the customer approved months earlier and forgot about.

The technical side security teams underestimate

Understanding this risk requires looking past the consent screen and into how OAuth tokens actually get abused once obtained. Token theft, replay, and authorization code interception attacks against OAuth flows are well-documented categories that penetration testers regularly find in production environments, not just theoretical edge cases. A deeper technical breakdown of these OAuth attack patterns is available for teams that want to understand exactly how a token gets exfiltrated or replayed once an attacker has a foothold.

Closely related is how the tokens themselves are structured. Many OAuth implementations issue JSON Web Tokens as access tokens, and a poorly validated JWT, one where the signature isn't properly checked, or where the algorithm can be downgraded, gives an attacker a way to forge a valid-looking token without ever stealing the real one. Reviewing how JWT signature validation works and where implementations commonly fail is a useful exercise for any team that assumes their token-based auth is inherently secure just because it uses an industry-standard format.

What a practical review process actually looks like

Closing this gap doesn't require rebuilding your integration architecture. It requires treating OAuth grants the same way security teams already treat user account permissions: with a periodic access review.

A workable process has three parts:

1. Maintain an inventory. Keep an actual list of every third-party app with API access to core SaaS platforms. Most identity providers and SaaS admin consoles already expose this list, it just needs to be pulled and reviewed rather than left buried in a settings page.
2. Cross-reference scope against usage. An integration that requested full read/write access to email eighteen months ago but hasn't made an API call in six months is a candidate for revocation, not renewal.
3. Scrutinize new requests. Treat new integration requests with the same scrutiny as a new employee's access request, asking specifically why a given scope is needed rather than accepting whatever the vendor's default OAuth request asks for.

None of this requires exotic tooling. Most major identity providers and SaaS platforms already surface connected app permissions somewhere in their admin console. The gap is rarely technical capability. It's that almost no organization has assigned clear ownership over reviewing it on a schedule, the same way they would for firewall rules or user access reviews.

The uncomfortable reality of API-based integrations and the broader attack surface they introduce is that they multiply an organization's actual attack surface far faster than anyone tracks it, because each one arrives disguised as a productivity improvement rather than a new access grant. Treating OAuth scopes as a permanent, unreviewed default is how a convenience feature quietly becomes the easiest way into an environment that otherwise looks well defended.