SaaS security

OAuth grant

An access token a user issues to a third-party application via OAuth, giving that app standing permission to read or write data inside another SaaS — often beyond MFA, often forever.

An OAuth grant is the durable access token a user issues when they click “Sign in with Google,” “Continue with Microsoft,” or “Connect to Slack” on a third-party application. Behind the friendly button, the user is consenting to a set of scopes — read your email, send mail on your behalf, list your calendar, edit your Drive files — that the receiving app can use long after the original session ends.

OAuth was designed to be safer than the alternative it replaced (password sharing). It largely succeeded, but it introduced a new class of risk: a token that survives the user, often survives the vendor relationship, and survives MFA entirely once issued. Defining properties:

  • Persists beyond the session. Most grants are valid until explicitly revoked. Refresh tokens can quietly rotate access tokens for years.
  • Bypasses MFA on use. MFA protects the grant ceremony; the token itself is bearer credentials. An attacker who phishes the consent screen never needs to face MFA again.
  • Often over-scoped. Developers ask for the broadest scopes that make their app work in the most cases; users approve in two seconds.
  • Invisible to traditional inventory. A grant doesn’t show up in your SaaS license inventory, your endpoint inventory, or your network logs.
  • Audited but rarely reviewed. Google Workspace and Microsoft 365 expose grant logs; few teams actually read them.

OAuth grants are the silent attack surface of the modern SaaS perimeter — the path used by OAuth phishing campaigns, by malicious browser extensions, and by perfectly innocent productivity tools that simply ask for too much. Continuously seeing every new grant, surfacing the risky ones, and nudging the user who issued them is what behavior-centered SaaS monitoring is built to do.

Related terms

See also