Every time a user clicks "Allow" on a Google consent screen, a third-party app gets a standing OAuth grant to that user's Gmail, Drive or Calendar, and most Google Workspace tenants have never counted how many of those grants exist. Those grants are non-human identities: they act without the user present, they survive password changes, and they are rarely reviewed. This guide shows how to build a complete inventory of third-party OAuth apps in a Google Workspace tenant from the three sources Google provides (the API controls app lists, per-user tokens in the Directory API, and OAuth log events), how to rank apps by the scopes they hold, and how to turn the inventory into access decisions. It is written for Workspace administrators and identity and security teams. Server-to-server access through domain-wide delegation works differently and has its own how-to, How to audit Google Workspace domain-wide delegation grants.
This is an independent guide from NHI Mgmt Group, based on Google's public Workspace admin and Admin SDK documentation as of November 2026. It is not sponsored or reviewed by Google. Admin console labels and edition features change, so confirm against Google's current documentation.
Key takeaways
- Use three sources, not one. The Admin console lists show which apps exist and their access setting; the Directory API
tokensresource shows which user granted which scopes; OAuth log events show when grants happened and, on some editions, whether the app is still calling APIs. - Key the inventory on the OAuth client ID. App names are not unique and can be changed by the publisher; the client ID is what access settings, tokens and log events all share.
- Rank by scope, then by reach. An app with full Gmail or full Drive scope held by a handful of executives can matter more than a calendar app used by thousands.
- The logs only go back six months. Google keeps OAuth token log events for six months, so grants older than that appear only in token lists, without a grant date. Start exporting now.
- Inventory leads to a default. The end state is that unconfigured apps are blocked or limited to sign-in information, and every app that touches Google data has an access setting and a named owner.
When you need this
Run this inventory when you have never reviewed third-party access, before tightening the setting for unconfigured apps, after a consent phishing incident, after a vendor reports a token theft, or as part of a periodic access review. The underlying risk is that a stolen or abused OAuth token gives an attacker API access to user data without a password or MFA prompt: MITRE ATT&CK tracks this as T1528 Steal Application Access Token and T1550.001 Application Access Token, and malicious app grants as a persistence route under T1671 Cloud Application Integration. Grants obtained through phishing links (T1566.002) are covered in depth in the Consent Phishing and Illicit OAuth Grants Guide. The Salesloft Drift breach showed how one integration's stolen OAuth tokens can open data across hundreds of customer tenants at once.
Before you start
- Admin roles: the API controls pages need the Service Settings administrator privilege; the OAuth log events in the audit and investigation tool need the Audit & Investigation privilege. Use a dedicated admin account, not a daily-use one.
- API access for scripts: listing tokens with the Directory API needs the
https://www.googleapis.com/auth/admin.directory.user.securityscope. Run collection with a dedicated, read-focused admin identity and record it in your NHI register; the collector is itself a privileged non-human identity. - Edition check: OAuth "API call" events, which show whether an app is still using its token, are available only on certain editions (Google lists Enterprise Plus, Education Plus, Enterprise Standard, Education Standard and Cloud Identity Premium). On other editions you will see grants and revocations but not usage.
- A register: a spreadsheet or database table keyed on client ID with columns for name, publisher, verified status, type, scopes, user count, organisational units, first grant, last activity, access setting, business owner and decision.
The three inventory sources
| Source | Where | What it gives you | Limits |
|---|---|---|---|
| Configured apps list | Admin console: Menu > Security > Access and data control > API controls | Apps with an access policy (Trusted, Limited or Blocked), with name, type, ID, verified status and access; the CSV from Download list adds number of users, requested services and API scopes | Only apps someone has configured |
| Accessed apps list | Same page, View list | Third-party apps users have used to access Google data, with user counts and requested services | Google says the list updates about 48 hours after a token is granted or revoked |
Directory API tokens.list | GET https://admin.googleapis.com/admin/directory/v1/users/{userKey}/tokens | Per user: clientId, displayText, scopes[], anonymous (true if the client ID is not registered with Google) and nativeApp (true for desktop or mobile installed apps) | One call per user; no grant date |
OAuth log events (Reports API applicationName=token) | Reporting > Audit and investigation > OAuth log events, or the Reports API | Events authorize, revoke, deny, request and activity with app name, client ID, client type and scopes; activity adds API name, method and response bytes; the console view can show IP and IP ASN | Kept for six months; lag of up to a few hours; activity events on certain editions only |
Step-by-step
1. Export the Admin console lists
Open Security > Access and data control > API controls. Under App access control, export Configured apps with Download list, then open the Accessed apps view and export that too. The Configured CSV gives you the access setting for every app that has one; the Accessed CSV shows apps users have actually used, including unconfigured ones. Click into any app with a broad scope list to see its full OAuth client ID, user count, privacy policy and requested scopes.
2. Pull every user's tokens
Enumerate users with the Directory API users.list, then call tokens.list for each user. Write one row per user and client ID with the scopes granted. This is the only source that tells you exactly which accounts hold a grant, which you need for revocation and for spotting grants by privileged users. Include suspended users: their tokens still matter if accounts are reactivated, and a long tail of grants on departed staff is a common finding. Respect API quotas by batching and backing off; for large tenants run it overnight.
3. Pull OAuth log events
Query the Reports API activities endpoint with applicationName=token for the full six-month window, or export from the OAuth log events page. From authorize events take the first grant date per user and client ID; from revoke events take removals; from request events take apps users asked to have approved; from activity events, where available, take the last date each client ID called an API. If you have BigQuery export or a SIEM, ingest these continuously so the six-month limit stops mattering for the future.
4. Merge into one register keyed on client ID
Join the three sources on client ID. For each app record: publisher (from the consent details and privacy policy link), verified status, whether it is internal to your organisation, total users, privileged users holding it, the union of scopes granted, first and last seen, current access setting and the business owner. Flag apps with anonymous set to true (unregistered client IDs), apps whose name appears under more than one client ID, and apps seen in tokens but absent from the Accessed list.
5. Rank by scope risk
| Tier | Example scopes | What the app can do | Default treatment |
|---|---|---|---|
| Critical | https://mail.google.com/, full https://www.googleapis.com/auth/drive, Admin SDK scopes | Read, send and delete all mail; read and change all files; change tenant settings | Named owner, security review, Trusted only if justified, otherwise Blocked |
| High | Gmail read or modify, Drive read-only on all files, Contacts write | Bulk read of mail or files; data exfiltration if the token is stolen | Owner and annual review; keep Gmail and Drive Restricted so untrusted apps cannot take these |
| Medium | Calendar read and write, file-picker style per-file Drive access | Read meeting data, act on files the user chooses | Limited; review at renewal |
| Low | openid, email, profile only | Sign in with Google, no Workspace data | Allow via the sign-in-only setting for unconfigured apps |
Google maintains its own predefined lists of high-risk Gmail and Drive scopes for the Restricted setting; use those as the authority for what "high-risk" means in your tenant and treat the tiers above as our working classification. Then weight by reach: number of users, number of privileged or executive users, and whether the publisher is verified.
6. Decide and set access
For each app, choose one of the settings Google provides: Trusted (can reach all services, including restricted ones), Limited (unrestricted services only), Specific Google data (offered when allowing an app from the pending review list; it requires the Google sign-in scope) or Blocked (cannot access any Google service). Apply settings per organisational unit where some teams have a genuine need. Then set the policy for everything you did not configure under the Settings card: either "Don't allow users to access any third-party apps" or "Allow users to access third-party apps that only ask for Google sign-in info". Under Manage Google Services, set Gmail and Drive to Restricted so that untrusted apps cannot obtain their high-risk scopes; Google notes that restricting a service revokes tokens for untrusted apps, so announce it first. Decide deliberately whether to tick Trust internal apps.
7. Revoke what should not exist
For blocked or unowned apps, delete the remaining grants per user with tokens.delete, which removes all access tokens a user issued to that client ID, and confirm with a fresh tokens.list. For an app suspected of compromise, revoke first and review later, then search OAuth activity events for that client ID to scope what it read. The Google Workspace Compromise Playbook covers the wider response.
8. Keep it current
Turn on the request flow so users ask instead of working around the block: requested apps appear under Apps pending review, sorted by number of user requests, and Google removes apps not configured within six months from that list. Alert on new authorize events for client IDs not in the register and for any grant of a critical-tier scope. See the Google Workspace Audit Log Detection Guide for alert patterns.
Decision points
| Situation | Choose | Trade-off |
|---|---|---|
| Small business, few apps, no security team | Sign-in-only for unconfigured apps, Gmail and Drive Restricted, a short Trusted list | Some user friction; very low effort to maintain. See Google Workspace for Small Business |
| Enterprise with many OUs | Block unconfigured apps, approve through Apps pending review, per-OU settings, register in IGA or CMDB | Needs an owner for the request queue; strongest control |
| Education tenant | Check edition-specific option names; the pending review flow is not available for Education | Under-18 users have separate Marketplace rules |
| App with critical scopes and a real business need | Trusted for the OU that needs it, named owner, quarterly review, activity alerting | Accepts concentrated risk in exchange for the integration |
| Unverified or anonymous client with broad scopes | Block and revoke, then ask users what they were using it for | May break a personal workflow; that is the point |
Verify it worked
- Coverage: every client ID found in tokens and logs appears in the register with a decision and an owner.
- Enforcement: with a test account in a pilot OU, try to authorise an unconfigured app that asks for Drive scope and confirm it is refused or routed to a request.
- Revocation: re-run
tokens.listfor affected users and confirm blocked client IDs are gone; check the Accessed list again after about 48 hours. - Logging: confirm the new
authorize,denyandrequestevents arrive in your SIEM within the lag Google documents.
Rollback and common errors
Access settings can be changed back per app and per OU, and changes can take up to 24 hours to apply, so roll out restrictive defaults to a pilot OU first and widen in stages. Revoked tokens cannot be restored: users must consent again, so tell owners before bulk revocation. Common mistakes:
- Inventorying from the Admin console only. The lists do not tell you which individual users hold a grant, so revocation and privileged-user analysis are impossible without the token API.
- Trusting the app name. A malicious app can copy a familiar name. Public reporting on the December 2024 Chrome extension compromises (see the Cyberhaven extension breach) describes attackers obtaining access through a single OAuth consent granted to a malicious app after a phishing email.
- Forgetting dormant grants. Tokens persist after the app falls out of use. The Vercel Context.ai breach shows how a forgotten AI app's token can still be stolen and used.
- Restricting Gmail or Drive without warning. It revokes tokens for untrusted apps at once and breaks integrations nobody knew about.
- Treating Trust internal apps as harmless. Internal apps built by staff can request critical scopes too; inventory them like third-party apps.
- Waiting for the six-month window to roll. Without continuous export, grant history is lost every month.
Where identity fits
Each OAuth grant is a delegated credential held by software, so the register belongs in your non-human identity inventory with an owner, purpose, scope and review date, like a service account. The same discipline applies across SaaS; see the SaaS OAuth App Governance Guide and the parallel How to audit GitHub Apps and OAuth apps in an organisation.
Measuring it
- Register coverage: share of client IDs with active tokens that have an owner and decision (target 100%).
- Critical-scope apps: count of apps holding critical-tier scopes, and the share that are Trusted with a current review.
- Unconfigured access: number of distinct unconfigured apps authorised in the last 30 days (should fall to near zero once defaults are set).
- Dormant grants: client IDs with tokens but no
activityevent in 90 days (where your edition logs activity). - Request turnaround: median days from an access request to a decision.
Framework mapping
| Framework | Reference | How this guide applies |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 System Component Inventory; SA-9 External System Services | Register of third-party apps keyed on client ID |
| NIST SP 800-53 Rev 5 | AC-6 Least Privilege; CM-7 Least Functionality; AC-20 Use of External Systems | Scope tiers, Restricted services, blocking unconfigured apps |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | OAuth log events review and alerting |
| NIST CSF 2.0 | ID.AM-02; GV.SC-04; PR.AA-05; DE.CM-03 | Inventory of services, supplier criticality, enforced access settings, monitoring |
| MITRE ATT&CK v20 | T1528; T1550.001; T1566.002; T1671 | Token theft and use, consent phishing, malicious app integrations |
Practitioner checklist
- Configured and Accessed app lists exported from API controls.
tokens.listrun for every user, including suspended users.- Six months of OAuth log events exported, and continuous export set up.
- Register keyed on client ID with owner, scopes, users, verified status and decision.
- Apps ranked by scope tier and by privileged-user reach.
- Every app with Google data access set to Trusted, Limited, Specific Google data or Blocked.
- Unconfigured apps blocked or limited to Google sign-in info; Gmail and Drive Restricted.
- Unowned and blocked grants revoked with
tokens.deleteand verified. - Apps pending review flow staffed, with alerts for new client IDs and critical scopes.
Standards and references
- Google: Control which third-party and internal apps access Google Workspace data
- Google: Review and manage third-party app access requests
- Google: Admin SDK Directory API tokens resource
- Google: Reports API OAuth Token activity events
- Google: OAuth log events
- Google: Data retention and lag times
- MITRE ATT&CK: T1528 Steal Application Access Token
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Google Workspace Security Guide, How to audit Google Workspace domain-wide delegation grants, SaaS OAuth App Governance Guide, Consent Phishing and Illicit OAuth Grants Guide and Google Workspace Audit Log Detection Guide.