An employee can leave a company, change departments or forget about an application they connected to their work account. That application may still have permission to access company data.
This is one of the easiest security gaps to overlook in Google Workspace. An OAuth approval is more than a sign-in convenience. Depending on the permissions granted, an application may read emails, access Drive files, send messages or interact with other organisational data.
For administrators, the challenge is knowing which applications have access, what they can do and whether they are still entitled to that access. A proper audit requires more than checking a list of connected apps. It involves examining OAuth scopes, activity logs, administrator policies and domain-wide delegation.
1. Start with the Google Workspace application inventory
The first place to investigate is the Google Admin Console. Sign in at admin.google.com and navigate to Security > Access and data control > API controls > Manage App Access.
Google separates applications into three useful inventories:
- Configured apps: Applications with an administrator-defined access policy.
- Accessed apps: Applications that have accessed Google data.
- Apps pending review: Applications users have requested permission to use.
Do not review only configured apps. An application can appear in the accessed-app inventory without having a specific administrator-configured policy.
Open each unfamiliar application and examine its full OAuth client ID, developer or ownership information, verification status, affected users, requested services, privacy policy and support details. Google also provides a CSV export, which makes it easier to build a central inventory and compare applications during subsequent reviews.
There is one timing detail worth remembering: Google says application information typically appears 24–48 hours after authorisation. A newly approved application might not immediately show up in the inventory.
2. Examine OAuth scopes instead of trusting application names
An application’s name does not explain how much access it has. OAuth scopes provide a more useful picture of its capabilities.
For example, an application that integrates with Gmail may request permission to read messages, modify mailbox content or send email. These are different capabilities and should not receive the same level of approval.
Some permissions deserve particular attention. Google’s list of high-risk OAuth scopes includes:
https://mail.google.com/– broad Gmail access.https://www.googleapis.com/auth/gmail.readonly– read Gmail messages.https://www.googleapis.com/auth/gmail.modify– read and modify Gmail data.https://www.googleapis.com/auth/gmail.send– send email.https://www.googleapis.com/auth/drive– broad Google Drive access.https://www.googleapis.com/auth/drive.readonly– read Drive files.https://www.googleapis.com/auth/drive.scripts– access associated with Drive scripts.
These permissions are not automatically evidence of malicious behaviour. A legitimate email-management tool might need Gmail access. The question is whether the requested permissions match the application’s actual purpose.
Google’s high-risk OAuth scope guidance provides the scope lists for services such as Gmail, Drive, Docs and Chat.
Consider a simple example: a calendar scheduling application requests permission to read and manage Calendar events. That is understandable. If it also requests permission to read Gmail messages and modify Drive files, the administrator should ask why those additional capabilities are necessary.
3. Apply the right access policy
After identifying an application’s permissions, examine its access policy. Google provides four principal settings for managing third-party and internal applications:
| Policy | What it permits |
|---|---|
| Trusted | Access to all Google Workspace services, including restricted services. |
| Limited | Access to unrestricted Google services. |
| Specific Google data | Access only to OAuth scopes explicitly permitted by the administrator. |
| Blocked | No access to Google Workspace data. |
For most third-party integrations, I would start by evaluating Specific Google data. It lets administrators approve the scopes an application actually needs instead of giving it unrestricted access.
Trusted should be reserved for applications with a clear business justification. It is a broad permission, not simply a label indicating that an administrator recognises the vendor.
4. Investigate what applications actually do
A permission grant tells you that an application received access. It does not establish whether the application subsequently used that access.
To investigate activity, open Reporting > Audit and investigation > OAuth log events in the Admin Console. Search for these event types:
authorize: A user authorised an application.activity: An application performed an API operation.revoke: Access was revoked.request: An application requested access.deny: An access request was denied.
The activity event deserves particular attention. Depending on the available event data, it can include the application name, OAuth client ID, API name, method name, Google product involved and response size in bytes.
For example, an administrator investigating an unfamiliar application could find API activity involving Gmail shortly after a user authorised it. That provides a starting point for checking whether the application’s behaviour matches its approved purpose.
These records are activity metadata, not copies of the emails or documents returned to an application. They should be correlated with relevant Gmail and Drive audit records when investigating suspected data exposure.
Administrators can also use the Google Workspace Reports API to retrieve OAuth token activity programmatically. Its documented reporting window is limited to the previous 180 days.
5. Do not overlook domain-wide delegation
Domain-wide delegation deserves separate attention because it creates an access path that is different from ordinary user consent.
With this configuration, an administrator can authorise a service account or application to access users’ Google Workspace data without requiring individual users to approve each request. Depending on the authorised scopes, the application can access data across the organisation.
Navigate to Security > Access and data control > API controls > Manage Domain Wide Delegation. A super administrator is required to manage these settings.
Review every client ID and its authorised OAuth scopes. Check whether the associated integration is still active, who owns it and why it needs delegated access.
A migration tool provides a useful example. It may need access to employee Drive files while transferring data into Google Workspace. Once the migration finishes, leaving its delegated permissions in place creates unnecessary exposure.
Google recommends using domain-wide delegation only when there is a critical business requirement. Where it is unavoidable, restrict scopes to essential permissions, protect service accounts and consider hosting them in dedicated Google Cloud projects.
6. Revoke unnecessary access and document the changes
When an application cannot be justified, administrators should take action rather than simply adding it to a watchlist indefinitely.
- Set the application’s access policy to Blocked through Manage App Access.
- Identify users who authorised the application.
- Revoke individual user tokens where necessary.
- Remove obsolete domain-wide delegation clients separately.
- Check legitimate integrations for operational impact.
- Record the reason for the action and retain relevant audit evidence.
For targeted revocation, Google’s Directory API provides a tokens.delete method. It deletes all access tokens issued by a specified user for a specified application. This is a per-user operation, not a single domain-wide token-revocation command.
Also remember that revoking access does not delete information an application may have previously copied. That requires a separate investigation and, where appropriate, a data-deletion request to the provider.
7. Make OAuth auditing a recurring security task
Google retains OAuth Token log events for six months. That gives administrators a limited period to investigate historical activity using the native audit records. Organisations that need longer retention should consider forwarding supported logs to Google Cloud Logging or another central monitoring platform.
A practical review should produce three records:
- Application inventory: Client IDs, owners, users, requested scopes and access policies.
- Risk register: Unverified applications, excessive permissions, unexplained activity and unused delegated access.
- Remediation record: Blocked applications, revoked tokens, removed scopes and approved exceptions.
For a small organisation, a monthly review may be a reasonable starting point. Organisations with sensitive data or frequent integrations should monitor new authorisations and high-risk access continuously, with periodic manual reviews.
The objective is straightforward: every application accessing company data should have an identifiable owner, a defensible business purpose and only the permissions it needs. When an integration no longer meets those conditions, its access should be removed.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
