Somewhere inside most large organizations sits a list nobody has looked at in years: every third-party application an employee has ever clicked “Allow” for. A scheduling tool that asked for calendar access. A resume-screening plugin that wanted read access to the applicant tracking system. A Chrome extension that requested permission to “see and change all your data on all websites” so it could summarize meeting notes. Each of those approvals created a standing, often unmonitored, connection into corporate systems — and in most companies, no one owns the job of checking whether it’s still needed, still scoped correctly, or still attached to a vendor that still exists.
This is the OAuth consent problem, and it has quietly become one of the more exploitable gaps in enterprise security, precisely because it doesn’t look like a security decision when it happens. It looks like a productivity click.
How the Access Actually Piles Up
OAuth and similar delegated-authorization protocols exist so that apps can talk to each other without users handing over their actual passwords. A marketing employee connects a social scheduling tool to the company’s Google Workspace account; a sales rep authorizes a note-taking app to sit inside their calendar and video calls; a developer links a CI tool to the company’s GitHub organization. Each grant issues a token — a credential that, unlike a password, doesn’t expire when the user changes their password, doesn’t show up in a login audit the same way, and often persists long after the person who created it has left the company or forgotten the integration exists.
Multiply that across a workforce of a few thousand people, several SaaS platforms, and years of accumulated clicking, and the result is a sprawling web of third-party access that maps to no inventory anyone maintains. Security teams that can name every server in their environment often cannot name every application with standing access to their email, file storage, or CRM.
Why This Is Different From the Usual Identity Problem
Most identity and access management programs are built around people: onboarding, offboarding, role changes, periodic access reviews. Some have extended that discipline to machine identities like service accounts and API keys used between internal systems. OAuth-connected third-party apps fall into an awkward gap between the two. The grant is initiated by a human, but the access is exercised by software the company doesn’t control and often can’t audit. The vendor on the other end may be a well-funded platform with a mature security program — or a two-person startup that will be acquired, pivot, or shut down within eighteen months, at which point the token it holds doesn’t automatically revoke itself.
That mismatch matters because the scope of what these apps request is frequently broader than what they need. A tool that only needs to read calendar availability may request full read/write access to email because that’s the permission tier the platform offers. Most users, faced with a consent screen, click through without evaluating the request — not out of carelessness, but because the screen is designed to be clicked through, and evaluating it properly would require security judgment the average employee hasn’t been trained to apply.
The Incidents Tend to Look the Same
When this category of risk surfaces publicly, it rarely involves a sophisticated zero-day. More often it’s a compromised or malicious third-party app that had been granted broad permissions months or years earlier, quietly harvesting email or files until something else — a data leak, an unusual export pattern, a tip from a researcher — draws attention to it. In other cases, the app itself was never malicious, but the vendor suffered a breach, and the attacker inherited every token the vendor’s platform was holding on behalf of its customers. From the victim organization’s side, nothing about their own environment changed. The exposure was already there, waiting.
Because these connections often don’t route through the same procurement or security review as a formal software purchase, they also tend to skip the vendor risk assessment that would normally apply. An employee doesn’t need a purchase order to grant OAuth access to a free browser extension; they need thirty seconds and a login.
What a Reasonable Program Looks Like
Addressing this doesn’t require exotic tooling, though dedicated SaaS security posture products exist and increasingly include OAuth-app visibility as a core feature. It requires treating third-party app authorization as an access decision rather than a productivity click, which in practice means a handful of concrete habits:
– **Inventory before policy.** Most identity providers and major SaaS platforms expose an admin view of connected applications and the scopes they’ve been granted. Pulling that list is usually the first time anyone sees the actual scale of the problem, and it’s worth doing before writing any new policy. – **Rank by scope, not by vendor size.** A small, obscure app with narrow read-only calendar access is a lower risk than a household-name tool that’s been granted full mailbox read/write. Review priority should follow the permission, not the logo. – **Set an expiration assumption.** Treat every OAuth grant as something that should be re-justified periodically — annually at minimum, tied to the same cadence as other access reviews — rather than something that persists silently until someone notices it. – **Kill dead integrations aggressively.** Apps tied to departed employees, discontinued vendors, or abandoned pilots are pure downside; they add attack surface with no offsetting benefit and are usually the easiest items to revoke. – **Restrict who can grant new access.** Some platforms allow admins to require approval before end users can authorize new third-party apps at all. That control adds friction, but it’s friction in the right place — before the access exists, rather than after it’s been exploited.
None of this eliminates the underlying tension between convenience and exposure that delegated authorization creates. But it moves the decision back into view, which is most of what’s missing today. The access is already there. The only question is whether anyone’s watching it.
