How to audit third-party OAuth apps in Google Workspace

By Patronum

August 10, 2026

Read Time: 5 mins

How to audit third-party OAuth apps in Google Workspace image

Why this audit matters
The audit, step by step
Risk tiers at a glance
What to record in your export
Where people get this wrong
Frequently asked questions
Make the audit repeatable
Sources

Open the Google Admin console and go to Menu > Security > Access and data control > API controls. That page lists every third-party app your users have connected, the OAuth scopes each one holds, and how many users granted it. From there you set each app to Trusted, Limited, or Blocked.

Audit state, not the log. The OAuth token log in Reporting records grant and revoke events as they happen. It tells you what changed and when, not who holds what access right now, and a grant older than your retention window isn’t in it at all. Current state comes from two places: the connected-apps view in the Google Admin console (API controls > Manage Third-Party App Access, plus each user’s Security page), and the Admin SDK, whose Directory API tokens.list “Returns the set of tokens specified user has issued to 3rd party applications.” Inventory first, log second.

Why this audit matters

Every OAuth grant is a standing key to your data, issued by a user, not by you. Google records each one as a “3-legged OAuth access token,” created when a user agrees to grant an app access to their Google service data. No admin approval is involved, and many OAuth grants can persist until revoked, unless affected by password changes, app controls, or other security policies. Google’s own guidance: “re-evaluate current access via the Admin console and revoke permissions if app access is no longer needed.”

The audit, step by step

1. List what is connected. Under Security > Access and data control > API controls, open Manage Third-Party App Access. Google shows how many users access each app plus the “Google service APIs (OAuth2 scopes) that each app is using.” Export it: that’s your inventory.

Warning before you touch the default. Blocking all unconfigured third-party API access is not a safe “tighten it and see” move. It breaks legitimate apps nobody configured yet, and it breaks Sign in with Google. Google’s own caution on the API controls page: “This setting blocks all OAuth scopes, including sign-in scopes, meaning that users will no longer be able to sign in with Google to third-party apps and websites.” Configure the apps you intend to keep first, then change the default.

2. Flag restricted scopes. Google keeps restricted scope lists for Gmail (compose, insert, modify, readonly, metadata) and Google Drive (full file access, metadata, scripts). Note that gmail.send is classed sensitive, not restricted. An app holding a restricted scope acts on real content, not just a name and email.

3. Set an access level per app. Trusted overrides a service restriction and reaches restricted services. Limited “can access only unrestricted Google services.” Blocked “can’t access any Google service.” Since December 3, 2024 you can also configure apps by select API scopes, which Google says “prevents apps from gaining additional access without admin consent.”

4. Pull the OAuth token log for history. In Reporting > Audit and investigation, the token audit report covers “third party websites and applications your users have granted access for.” Google keeps those events for six months, lag “up to a few hours.”

5. Revoke per user. A user’s Security page shows “all active 3-legged OAuth 2.0 tokens for a given user for a given application,” and Google is clear that listing and revocation happen user by user, app by app. No button clears every grant domain-wide.

Google Admin console API controls, the accessed apps list showing app name, client ID, number of users, requested services and access status

Risk tiers at a glance

Tier	What it means	Typical action
Restricted scopes, many users	Reads or sends Gmail, reads all Drive	Trust after review, scope by API
Restricted scopes, one user	Personal add-on, deep access	Ask the user, usually Block
Sign-in only	Name, email, profile	Limited is fine
Unconfigured	No decision yet	Set a default
Former employee’s grants	Token live on a suspended account	Reset password, then revoke

What to record in your export

Export the app list to CSV with these eight columns, so next quarter is a diff, not a fresh start.

Column	What goes in it
App name	As shown in API controls
Client ID	The only stable identifier
Users	Number who granted it
Scopes	Flag restricted Gmail and Drive scopes
Risk tier	From the table above
Owner	Who answers for it internally
Decision	Trusted, Limited, Blocked, or scoped by API
Review date	When you last checked it

Where people get this wrong

Suspending an account is not the same as revoking its OAuth grants. Google’s suspension documentation says services become “unavailable to the user,” but never says third-party tokens are revoked. Google’s authorized access page states only that “OAuth 2.0 tokens issued for access to certain products are revoked when a user’s password is changed.” A partial safety net. The leaver sequence: reset the password, revoke tokens app by app on the Security page, then check the log.

The second trap is Google Drive. Google’s transfer documentation is blunt: “Transferring files does not affect who has access to the files.” Ownership changes, sharing doesn’t.

Patronum’s offboarding automation runs the account-side steps in the same order every time: password reset, recovery email, app-specific passwords, device wipe, group membership, plus shared-file cleanup on the Drive side. If the mailbox has to outlive the account, Patronum Archive keeps that email and its Google Vault data searchable in storage you own. Revocation itself stays an Admin console job. For forensic-depth app auditing, GAT Labs is audit-first and genuinely deeper on event-level investigation.

Frequently asked questions

How do I see what apps have access to my Google Workspace account?

Go to Menu > Security > Access and data control > API controls > Manage Third-Party App Access. Each app shows its OAuth2 scopes and how many users granted access. For one person, check their user record’s Security page.

Does suspending a Google Workspace user revoke third-party app access?

Not reliably. Google’s suspension documentation says services become unavailable, but never states that OAuth tokens are revoked. Revoke explicitly, per user and per app.

How far back can I audit OAuth grants?

Six months of log history. Google retains OAuth Token log events for six months, with a lag of up to a few hours. That log records events, not current access, so pair it with an inventory export.

Make the audit repeatable

Run this quarterly, paired with a real leaver process. Patronum’s user offboarding checklist for zero data leakage covers the sequence, and Google Workspace management at scale covers what happens when manual review stops scaling.