How to Audit Third-Party OAuth Apps in Google Workspace

Ask most IT admins how many third-party applications have access to their Google Workspace data and you will get a guess, not a number. That uncertainty is the problem. Every time a user clicks "Sign in with Google" or installs a Marketplace add-on, they grant an OAuth application a durable slice of access to organizational data — and that grant outlives the user's interest, the vendor's relevance, and often the admin's awareness.

This article is a practical method for auditing those grants: where to find them, how to judge which ones are risky, and how to clean up safely.

What an OAuth grant actually is

When a user authorizes an app "with Google," they are not handing over their password. They are granting the application a token scoped to specific permissions — *scopes* — that let it call Google APIs on the user's (or organization's) behalf. A scope might be as narrow as "see your email address" or as broad as "see, edit, create, and delete all of your Google Drive files."

Two properties make these grants worth auditing:

• They persist. A token keeps working until it is explicitly revoked, the app is removed, or the account is disabled. "I stopped using that tool a year ago" does not revoke anything.
• They are user-initiated. Access is granted by the person who clicked "Allow," not provisioned by IT. That is the textbook definition of shadow IT, and it means your access inventory is incomplete by default.

Where to find the inventory

There are two vantage points.

The user's view lives at each person's Google Account, under *Security → Third-party apps & services* (formerly "Apps with access to your account"). It shows what one user has authorized. Useful for spot checks, impractical at scale.

The admin's view lives in the Google Admin console, under *Security → API controls → App access control* (and the connected-apps reporting alongside it). This is the organization-wide picture: which apps are connected, which scopes they hold, and how many users authorized each one. For an audit, this is where you work.

If you have the appropriate admin privileges, the Admin SDK's token reporting can enumerate the same data programmatically, which is what makes continuous, automated review possible rather than a once-a-year manual slog.

How to judge risk

Not every connected app is a problem. A calendar scheduling tool that can read free/busy times is low risk; a note-taking app with full Drive access used by one person is a different story. Score each app on a few dimensions:

• Scope breadth. Full Drive access, Gmail read/send, and admin directory access are the high-stakes scopes. An app that can read and exfiltrate every file is your top priority regardless of how trusted it seems.
• Sensitivity of what it can reach. Drive content and mailbox access outrank profile or calendar metadata.
• User count and breadth. An app one person uses but that holds wide access is a quiet, concentrated risk. An app the whole company uses deserves scrutiny because its blast radius is large.
• Publisher trust. Verified publishers and well-known vendors are safer bets than unverified or anonymous apps. Google's app-verification status is a useful signal, not a guarantee.
• Activity. An app nobody has used in months is pure downside: all of the risk, none of the value.

A simple way to combine these: anything with a high-stakes scope *and* low trust *or* no recent use goes to the top of the cleanup list.

A repeatable audit, step by step

1. Enumerate. Pull the full list of connected apps and their scopes from the Admin console (or via the API).
2. Classify scopes. Flag the dangerous ones — full Drive, Gmail send/read, directory, and any admin scopes.
3. Cross-reference usage. Identify apps with no recent activity and apps held by very few users.
4. Check the publisher. Note unverified or unknown publishers.
5. Decide. For each app: keep, restrict, or revoke. Document the reason — the decision log is what makes the next audit faster.
6. Revoke safely. Remove access for the apps you have decided to retire, and communicate with the handful of users who relied on a tool you are removing.
7. Set guardrails. Move from cleanup to prevention: restrict Marketplace installs to admin-approved apps, and block or allow-list access to high-risk scopes so the sprawl does not simply regrow.

Revoking without breaking things

The fear that stops most cleanups is "what if I revoke something people need?" Mitigate it:

• Start with the unambiguous wins: unverified apps with broad scopes and zero recent use.
• For apps with a small user base, send a heads-up before revoking; if nobody objects, proceed.
• Keep a record of what you revoked and when, so if something does break you can restore it quickly and deliberately.

Revocation in Google's tooling is immediate and reversible — a user can always re-authorize an app they genuinely need, this time with your guardrails in place.

Make it continuous

A one-time audit feels great and decays immediately. New apps get connected the day after you finish. The durable answer is continuous discovery: automatically enumerate connected apps and their scopes, score each one, and alert when a new high-risk grant appears or a dormant app holds broad access.

That shift — from periodic spreadsheet to always-current inventory — is the difference between knowing your OAuth exposure today and guessing at it. It is also one of the pillars of broader Google Workspace security, alongside identity, sharing, and configuration.

The scopes that should make you pause

Because scope breadth is the single biggest risk factor, it helps to know which OAuth scopes carry real weight. A few patterns worth recognizing when you read an app's permission list:

• `drive` (full Drive) — read, create, modify, and delete *all* of a user's Drive files. This is the broadest data scope an app can hold, and it is far more common than it should be; many apps request it when a narrower per-file scope would do.
• `gmail.send` / `gmail.modify` / `mail.google.com` — the ability to send mail as the user, or read and modify the mailbox. An app with mailbox access can both exfiltrate correspondence and impersonate the user to others.
• **admin.directory.*** — read or manage your directory of users and groups. An app holding this reaches across the whole organization, not just one user.
• `spreadsheets` / `documents` — content access to Sheets and Docs, which frequently hold exactly the sensitive data (financials, plans, credentials pasted "temporarily") you most want to protect.

Narrow, read-only scopes — userinfo.email, calendar.readonly, drive.file (access only to files the app itself created) — are the ones to encourage. When you evaluate a new tool, prefer the version that asks for the least.

Turning the audit into a policy

A clean audit is worth far more if it ends in a standing policy rather than a one-time purge. Three policies prevent most of the sprawl from regrowing:

• Admin-approved Marketplace installs. Require administrator approval before users can install Marketplace apps, so new connections are a decision rather than a default.
• Scope-based access control. Block or explicitly allow-list the high-risk scopes (full Drive, Gmail, directory). An app that wants full Drive access should clear a bar; an app that wants only an email address should not.
• A recurring review owner. Assign someone the standing job of reviewing new and high-risk grants on a schedule. Unowned reviews do not happen.

These guardrails change the default from "any user can grant any app any access" to "broad access is a deliberate, reviewed choice" — without blocking the legitimate tools people genuinely need.

8200.dev discovers the third-party apps connected to your Workspace, scores them by scope, publisher trust, and usage, and surfaces the risky ones first — read-only and continuously. See what we check for the full picture.

Want to see which apps can reach your data right now? Start your free security audit and get an inventory of connected OAuth applications, ranked by risk, across your Google Workspace.