OAuth security is how organizations govern third-party application access granted through the OAuth 2.0 protocol. OAuth lets a client app obtain an access token to act on behalf of a user without handling the user's credentials, which is why unreviewed or over-scoped grants are a direct path into Gmail, Drive, and other cloud workspace data. Effective OAuth security combines continuous discovery of authorized clients, runtime behavior analysis, and the ability to revoke tokens immediately when something turns malicious.

When a user installs a third-party app, the app sends an authorization request to the workspace's authorization server (like Google). The user sees a consent screen listing the requested scopes and approves them. The authorization server returns an authorization code, which the client exchanges for an access token, presenting its client id and client credentials. The client uses that access token to call APIs against protected resources like Gmail. Refresh tokens let the client renew access without prompting the user again, which is the source of most OAuth persistence problems.

An OAuth access token is a credential a client application presents to an API to prove it has been authorized to act on a user's behalf. Access tokens are typically short-lived bearer tokens, meaning anyone in possession of the token can use it until it expires or is revoked. Most OAuth breaches involve attackers obtaining valid access tokens (or the refresh tokens used to renew them) and using them to read email, exfiltrate files, or call APIs without triggering a new authentication event.

Consent phishing is a social engineering attack where a malicious OAuth client tricks a user into approving an authorization request, typically by impersonating a legitimate vendor on the consent screen. Because the user technically approves the grant themselves, the attacker walks away with a valid access token and the activity bypasses traditional credential-theft alerts. Continuous monitoring of new OAuth grants is the only reliable defense, since the attack succeeds at the consent step rather than the login step.

Most OAuth breaches follow one of three patterns. A user is tricked into approving a malicious app through consent phishing. A legitimate third-party vendor with valid OAuth grants is compromised, and the attacker uses those existing tokens to reach customer data (the pattern behind the Vercel and Heroku-Travis CI incidents). Or long-forgotten apps with broad scopes are exploited months or years after the original authorization. All three bypass MFA because the attacker is using a valid token, not logging in.

MFA does not stop OAuth abuse because a valid access token survives password resets and MFA resets. Once a user has approved a malicious client, the attacker holds a working token that calls APIs directly, never triggering a fresh login or multi-factor authentication challenge. The only reliable response is revoking the token at the authorization server, which is what Material automates.

OAuth sprawl is the accumulation of hundreds or thousands of authorized clients across an organization, each with different scopes and authorized by different users at different times. It grows fastest in environments that have adopted AI tools quickly. Material's research on OAuth app sprawl in Google Workspace covers the dynamic in detail.

Traditional SSPM tools poll for permission snapshots and flag broad scopes after the fact. Material monitors what each authorized client is actually doing inside the workspace and can revoke tokens the moment behavior turns suspicious. The difference is active defense versus a compliance report.

Yes. AI agents authenticate through the same OAuth flows as any other client, so they get the same continuous discovery, classification, and automated revocation as traditional SaaS integrations.