700+

companies reached through one compromised OAuth integration

2025

FINRA

1,000+

average measured apps vs <10 believed connected to M365

2024

AppOmni

48%

of breaches involve a third party

2026

Verizon DBIR

Every 'Sign in with Google' click created a standing grant, and the full list usually surprises whoever opens it first.

what it is

OAuth is the protocol that allows one application to access resources in another on behalf of a user. In practice: when an employee connects a new tool to Google Workspace or Microsoft 365 and clicks "Allow," the application receives an OAuth grant. That grant specifies the scope of access, which might include reading mail, accessing calendar events, viewing or editing files, or reading the contact list.

The grant is persistent. It does not expire when the user stops using the application. It does not expire when the user changes roles. It does not expire when the user leaves the company. It remains active until someone explicitly revokes it.

An OAuth grant audit is the process of pulling every active grant in an environment, reviewing what each application can access and whether it still should, and revoking grants that are no longer needed or that hold broader access than their function requires.

why it accumulates

The mechanism that creates OAuth accumulation is built into how cloud tools work.

Every integration a user creates, every app they connect for convenience, every third-party tool that asks for workspace access: each one creates a grant. The user may use the tool for a week and move on. The grant stays.

No system sends a notification when a grant is no longer being actively used. No system warns when the application attached to a grant changes hands, is acquired, or shuts down. The user who created the grant may have left the company, leaving an active application permission attached to their account, which itself may still be active.

Most organizations have no single view showing all active OAuth grants. The grants exist in the application layer, not in the directory. Without a tool that specifically reads OAuth grant data from the IdP, the list is invisible.

what it costs you

Active access through departed accounts. When an employee leaves and their directory account is closed, OAuth grants attached to that account may still carry live access. If the application can re-authenticate using the grant's refresh token, it can continue reading data from your workspace after the user is gone.

Applications with excessive access to sensitive data. A tool that only needs to send notifications has no business reading your full mailbox. A signing tool has no need to access your contacts. Grants are issued at the scope the application requests rather than the minimum scope its function requires. Broad scopes granted without review create wide access paths from your environment to third-party systems.

Dormant grants from abandoned tools. Applications that were tested, tried for a short period, or adopted and then dropped still hold active grants. Some of those vendors may have changed their data practices, been acquired by another company, or ceased operation. The grant remains and its trust status has changed without you knowing.

Compliance exposure. GDPR Article 28 requires processor agreements for every third-party that handles personal data on your behalf. OAuth-connected applications processing your users' data are processors. Without an audit, you do not know how many you have or whether agreements are in place.

what works

The raw material comes straight from the identity provider: Google Workspace, Okta, and Microsoft Entra each expose the full OAuth grant list through their admin consoles or APIs, with the application name, the granted scope, the user who authorized it, and the date of the most recent authorization. Cross-referenced against the application registry, the list sorts itself. Grants from unrecognized applications come first, and grants from known tools get checked against the scope they actually hold rather than waved through on familiarity.

Two categories justify immediate revocation rather than review. Grants attached to inactive or departed accounts go first, because directory offboarding does not revoke OAuth grants, and an application holding a refresh token can keep reading workspace data long after the user is gone. The second is the mismatch between scope and function: a notification tool holding full mailbox read access, a signing tool that can read contacts. Where the tool supports it, revoking and re-authorizing at a narrower scope keeps the function and drops the excess; where it does not, the choice sits between accepting a documented risk and replacing the tool.

What keeps the backlog from re-forming is cadence rather than heroics. A quarterly or half-yearly review that covers only what changed, new grants since the last pass, grants on high-privilege accounts, and grants in the high-scope category, stays small enough to actually happen. The exhaustive annual review that everyone dreads tends to slip indefinitely, while the bounded review that runs on schedule catches drift while it is still small.

practical guides you might find useful

let's start with a conversation

Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.

Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.

We'll take it from there

Julian Machowski
Head of Technical Sales
+48 783 762 997
julian@unshadowit.com
Let's connect on LinkedIn
Message received. We'll be in touch soon.
Something failed. Try again or call us directly.