OAuth is an open authorization standard that allows applications to access resources on behalf of a user without requiring the user to share their credentials directly.

‍

Main takeaways

• OAuth enables the "Connect with Google/Slack/Microsoft" integrations that employees authorize daily—each creating a persistent access grant that may outlast its original purpose by months or years.
• OAuth grants are access decisions, not just convenience features. Each grant defines what one application can do inside another on a user's behalf, with permissions that often exceed what the use case requires.
• Most organizations have hundreds or thousands of active OAuth grants they've never inventoried. Many are over-permissioned, stale, or connected to applications that no longer serve an active function.
• Revoking an employee's primary account in the IdP doesn't automatically revoke their OAuth grants—those connections may persist in third-party applications indefinitely.
• OAuth-connected applications represent a significant and largely ungoverned portion of the modern SaaS attack surface.

What is OAuth?

Before OAuth, granting one application access to another required sharing credentials—giving application B your username and password for application A so it could act on your behalf. That pattern was a credential security nightmare. OAuth replaced it with a delegated authorization model: the user grants a specific, scoped permission to an application without sharing credentials at all. The application receives a token representing that permission, not the underlying credential.

‍

In practice, OAuth is what powers every "Connect your account" flow. When an employee authorizes a productivity tool to read their calendar, a reporting tool to access their Salesforce data, or an AI assistant to read their email, they're creating an OAuth grant. The authorization happens through the service provider, the user approves specific scopes, and the application receives a token it can use to make requests on the user's behalf.

‍

The OAuth integration sprawl problem

The convenience of OAuth is also what makes it a governance challenge at scale. Each individual grant is easy to create and requires no IT involvement. Multiplied across hundreds of employees authorizing dozens of applications each, the result is a web of active access grants that nobody has a complete map of.

‍

Several structural problems compound the risk:

• Scope overreach—Applications frequently request broader permissions than their stated functionality requires. Users approving these grants rarely scrutinize the scope.
• Persistence—OAuth tokens don't have a standard expiration. A grant made years ago by an employee who has since left may still be active.
• Offboarding gaps—Deprovisioning an employee in the IdP terminates their ability to authenticate. It does not revoke OAuth grants those credentials enabled—third-party applications may retain active access.
• SaaS-to-SaaS connections—OAuth grants between SaaS applications create access pathways that don't involve a human user at all, and that sit outside the visibility of most identity governance tools.

Security considerations

From an attacker's perspective, OAuth grants are attractive targets precisely because they persist and are poorly monitored. A compromised account that has granted OAuth access to a dozen connected applications represents a much larger blast radius than a compromised account with no integrations.

‍

Effective governance requires discovering all active OAuth grants, reviewing them against current business need, revoking those that are stale or over-permissioned, and ensuring that offboarding processes include OAuth revocation—not just IdP deprovisioning.

‍

See how Nudge Security maps OAuth grants and SaaS integrations across your organization →