How to Audit and Revoke Third-Party Apps in Google Workspace: Complete Security Guide

Third-party applications are an important part of the Google Workspace ecosystem. They connect Gmail, Google Drive, Calendar, and other services to productivity platforms, CRM systems, document management tools, and business applications.

However, every connection introduces a potential security risk.

Employees may authorize applications without involving the IT department. Some apps request extensive permissions, while others retain access after a project ends or an employee leaves.

Over time, organizations can accumulate dozens or hundreds of OAuth connections without maintaining a clear inventory.

This creates a significant challenge for Google Workspace administrators: identifying which applications are connected, understanding what they can access, and removing permissions that are no longer justified.

In this guide, we explain how to audit third-party applications in Google Workspace, review OAuth scopes, revoke access, and strengthen application governance.

AI Summary: How to Audit Third-Party Apps in Google Workspace

To audit third-party applications in Google Workspace, open the Google Admin console and navigate to Security > Access and data control > API controls > Manage third-party app access.

Administrators can use these controls to review connected applications, examine requested access, and configure restrictions.

A complete third-party application audit should include:

1. Identifying applications connected to Google Workspace.
2. Reviewing the users associated with each application.
3. Checking OAuth permissions and access to Gmail, Drive, Calendar, or other services.
4. Identifying unknown, unnecessary, or high-risk applications.
5. Reviewing access associated with former employees.
6. Restricting or blocking unauthorized applications.
7. Revoking existing OAuth tokens where appropriate.
8. Establishing a regular application review process.

Important: Blocking an application through an administrative policy and revoking an existing OAuth token are related but distinct operations.

MOZAYK Workspace provides a Shadow IT & SaaS module designed to help administrators gain visibility into connected applications and identify access-related risks.

1. What Are Third-Party Apps in Google Workspace?

A third-party application is software developed outside Google that connects to a Google account or Google Workspace service.

Examples include:

• CRM platforms.
• Project management tools.
• AI assistants.
• Document signing services.
• Scheduling applications.
• PDF editors.
• Marketing automation tools.
• Meeting transcription services.
• Reporting and analytics platforms.

These integrations can improve productivity, but they may also access information stored in Google Workspace.

For example, an application connected to Google Drive might request permission to view specific files or broader access to a user's Drive content.

An email automation platform might request permission to send messages, while a scheduling application may need to read or modify calendar events.

The level of risk depends on the actual permissions granted, the application's security practices, and the business context.

2. What Is OAuth and Why Does It Matter?

OAuth is an authorization framework that allows applications to request access to supported resources without requiring users to share their account passwords directly with those applications.

When an employee connects an application to Google Workspace, they may see a Google authorization screen describing the requested permissions.

If authorization succeeds, the application may receive access tokens and, depending on the authorization flow and granted permissions, refresh tokens.

These credentials allow the application to perform authorized operations.

OAuth Is Not the Same as Sharing a Password

With OAuth, users generally do not provide their Google account password to the connected application.

However, the resulting authorization may still grant significant access to company information.

For example, an application may be authorized to read emails, access files, or manage calendar events.

The absence of password sharing does not eliminate the need for security review.

What Are OAuth Scopes?

OAuth scopes define the categories of permissions an application requests.

For example:

The exact scope matters.

An application requesting access to a single user-selected file does not necessarily have the same level of access as an application requesting broad Drive permissions.

Administrators should evaluate the permissions actually requested and granted rather than relying only on the application's name.

3. Why Third-Party Apps Create Security Risks

Many applications are legitimate and necessary for business operations.

The objective of an audit is not to block every integration. It is to ensure that access is understood, approved, and appropriately restricted.

Excessive Permissions

An application may request broader access than its business function appears to require.

For example, a PDF utility requesting broad access to Google Drive should be reviewed carefully.

Unapproved Applications

Employees may connect applications without involving IT or security teams.

This practice is commonly associated with Shadow IT.

Persistent Authorization

An employee may stop using an application while its authorization remains active.

Depending on token validity, application behavior, and organizational policies, access may continue until it expires or is revoked.

Compromised Application Vendors

A security incident affecting a third-party provider may create risks for connected organizations.

The potential impact depends on the application's permissions, exposed credentials, and other controls.

Former Employee Connections

Applications previously authorized by departing employees should be reviewed during offboarding.

A suspended or inactive account should not be treated as proof that every associated integration has been fully deprovisioned.

Unnecessary Data Exposure

An application may collect or retain information outside Google Workspace.

Revoking its future access does not automatically delete data it has already received.

4. How to View Third-Party Apps in the Google Admin Console

Google Workspace provides native controls for reviewing applications that access organizational data.

Step 1: Sign in to Google Admin

Open:

https://admin.google.com

Sign in using an administrator account with the required privileges.

Step 2: Open API Controls

Navigate to:

Security > Access and data control > API controls

Depending on the Admin console interface, select the option to manage third-party application access.

Step 3: Review the Application Inventory

The application access interface provides information about applications associated with your organization's Google Workspace environment.

Depending on the application and available details, administrators can examine information such as:

• Application name.
• OAuth client identity.
• Access configuration.
• Requested Google API services or scopes.
• Associated users and access activity where available.

The available information can vary according to the organization's edition, privileges, and Google Admin console interface.

Step 4: Identify Applications Requiring Review

Look for applications that are:

• Unknown to the IT department.
• No longer needed.
• Connected to sensitive Google services.
• Associated with former employees.
• Duplicated across different tools.
• Unnecessarily privileged.
• Approved without a documented business requirement.

An unfamiliar application is not automatically malicious.

It should first be investigated and classified.

5. How to Audit OAuth Permissions and Scopes

Application names alone provide insufficient information for a security decision.

A proper audit should evaluate the actual permissions requested.

Review Access to Sensitive Services

Pay particular attention to applications requesting access to:

• Gmail messages.
• Google Drive files.
• Administrative APIs.
• User information.
• Shared business calendars.
• Sensitive organizational data.

The distinction between read-only access and the ability to modify or delete information is especially important.

Compare Permissions with Business Needs

Ask the following questions:

1. Who uses the application?
2. What business process does it support?
3. Which Google services does it access?
4. Are all requested permissions necessary?
5. Is the application approved by IT?
6. Is there an alternative with narrower permissions?
7. What happens if the application is compromised?

For example, an application whose only purpose is to schedule meetings may not need unrestricted access to every Google Drive file.

Examine the Vendor

Review the provider's identity, security documentation, privacy policy, contractual arrangements, and data handling practices.

An application appearing in a marketplace or using Google's OAuth interface should not automatically be considered risk-free.

6. How to Restrict or Block Third-Party Apps

Google Workspace administrators can configure application access policies through the Admin console.

The available controls include access settings such as:

The exact options and behavior depend on Google's current configuration model.

How to Change an Application's Access

1. Open the Google Admin console.
2. Navigate to Security > Access and data control > API controls.
3. Open the third-party app access management interface.
4. Locate the application.
5. Review its current access configuration.
6. Select an appropriate restriction.
7. Save the change.
8. Verify the impact on affected users and workflows.

Should Every Application Be Trusted?

No.

Trusted status should be reserved for applications that have been appropriately reviewed and require the associated access.

An application may only need access to a limited set of Google services.

Where supported, a more restrictive configuration is preferable to granting broad access unnecessarily.

Can Administrators Require Approval for New Apps?

Google Workspace provides app access control capabilities that can be used to restrict access to services and allow approved applications.

A practical governance approach is to classify required applications, establish appropriate restrictions, and implement an internal approval process.

This does not mean every Google Workspace edition provides a universal, automatic approval workflow for every new SaaS connection.

The enforcement depends on the policies configured and the Google APIs involved.

7. How to Revoke OAuth Access in Google Workspace

Revoking OAuth access prevents an application from continuing to use the affected authorization, subject to token and service behavior.

However, there are different administrative operations to consider.

Option 1: Remove Access from an Individual Google Account

A user can review applications connected to their Google account.

Open:

https://myaccount.google.com/connections

Select the relevant application and examine the access it has been granted.

If appropriate, remove the application's access.

The available actions depend on the type of connection.

This approach affects the selected account and connection.

Option 2: Revoke Tokens Through Administrative Controls

Google Workspace administrators can review OAuth token information for users through supported administrative tools.

Depending on the available interface and permissions, they can revoke existing OAuth authorizations.

The exact process may involve user-specific security settings or supported administrative actions.

After revocation, verify that the affected application no longer has the intended access.

Option 3: Block the Application Organization-Wide

Administrators can use API controls to block an application from accessing covered Google Workspace data.

This is useful when an application is unauthorized or presents an unacceptable risk.

However, an application-wide restriction is not identical to individually revoking every previously issued token in every context.

For a security incident, review both the application policy and the affected authorizations.

Important: Revocation Does Not Delete Previously Exported Data

If an application previously downloaded emails, documents, or customer records, revoking access does not automatically erase those copies.

An incident response process may also require contacting the vendor, investigating data processing, and following the organization's contractual and regulatory procedures.

8. How to Audit Apps Connected to Former Employees

Employee offboarding is a particularly important use case.

When an employee leaves, administrators typically review the account, email, files, groups, and device access.

Third-party applications should also be included.

Example: A Departing Employee

Imagine a sales employee used Google Workspace to connect:

• A CRM platform.
• A PDF editing service.
• A meeting transcription tool.
• An AI assistant.
• A scheduling application.

Before departure, the employee had authorized these applications to access certain Google services.

Even if the applications were legitimate, the organization must determine whether those authorizations should remain.

Recommended Offboarding Procedure

1. Identify applications authorized by the employee.
2. Review the relevant OAuth permissions.
3. Determine whether any application supports a critical business workflow.
4. Transfer ownership or operational responsibility where necessary.
5. Revoke unnecessary authorizations.
6. Review shared integration accounts and service accounts.
7. Disable or remove the employee's access according to the offboarding process.
8. Verify that no unsupported business dependencies remain.

A Critical Distinction

A user account may be suspended while an application record or authorization history remains visible.

The presence of a record does not, by itself, prove that the application can still access organizational data.

Administrators must distinguish current authorization, historical activity, and effective access.

9. How to Investigate OAuth Activity

Google Workspace provides OAuth-related audit events in supported administrative reporting interfaces.

These records can help administrators investigate application authorization and related activity.

Depending on the organization's edition and available capabilities, administrators may examine:

• OAuth authorization events.
• The user associated with an event.
• Application or client identifiers.
• Requested or granted scopes.
• Relevant event timestamps.

Availability, detail, retention periods, and investigation tools may vary.

When Should OAuth Logs Be Reviewed?

We recommend reviewing them when:

• An unfamiliar application appears.
• A user reports suspicious behavior.
• A security incident affects an application vendor.
• A departing employee had access to sensitive data.
• An organization changes its SaaS policies.
• An application unexpectedly requests additional permissions.

OAuth logs can contribute to an investigation, but they do not necessarily reveal every action performed by an external application.

Additional evidence may be required from the application vendor or other Google Workspace logs.

10. What Is Shadow IT in Google Workspace?

Shadow IT refers to technology used within an organization without appropriate visibility, approval, or governance by its IT function.

In Google Workspace, this may include applications authorized directly by employees through their Google accounts.

Examples include:

• Unapproved AI productivity tools.
• Personal file conversion services.
• Alternative project management platforms.
• Meeting recording applications.
• External document automation services.

Shadow IT is not necessarily malicious.

Employees often adopt these tools to solve legitimate productivity problems.

The risk arises when applications access corporate information without appropriate security and contractual oversight.

How to Reduce Shadow IT

Organizations should:

1. Maintain an inventory of connected applications.
2. Identify application owners.
3. Review requested OAuth scopes.
4. Establish an approval process for new tools.
5. Apply Google Workspace API access restrictions.
6. Periodically review unused applications.
7. Include SaaS access in employee offboarding.
8. Communicate clear application security requirements.

An effective approach combines technical controls with practical business processes.

11. Classifying Third-Party Applications by Risk

Not every connected application requires the same response.

A risk-based classification helps administrators prioritize their work.

The classification should account for the user's role, the data involved, the application's permissions, and the supplier's trustworthiness.

An application requesting a sensitive scope is not automatically malicious, but it may warrant closer scrutiny.

12. Audit Third-Party Apps with MOZAYK Workspace

Google Workspace administrators can use native API controls to configure application access.

However, reviewing a large number of users and connected applications can become operationally demanding.

MOZAYK Workspace includes a Shadow IT & SaaS module designed to provide visibility into third-party applications associated with Google Workspace.

The platform brings application-related information into the broader Google Workspace administration environment.

This helps IT teams review connected SaaS tools, investigate applications requiring attention, and support access governance.

Why Centralized Visibility Matters

Application management involves more than identifying a software name.

Administrators need to consider:

• Which applications are connected.
• Which users are associated with them.
• Whether the access is still necessary.
• Whether former employees have left behind application connections.
• Which applications require further security review.

Combining these observations with user and access management provides a more complete view of the organization.

Shadow IT and Employee Offboarding

MOZAYK Workspace also includes employee lifecycle features. When someone leaves, also check their Drive files: see how to transfer ownership of Google Drive files and Shared Drive roles and permissions.

This creates a useful connection between managing user accounts and reviewing application access during employee departures.

For example, administrators may identify connected applications that should be reviewed as part of an offboarding procedure.

What MOZAYK Workspace Does Not Replace

MOZAYK Workspace is not a substitute for Google's native API access controls, a comprehensive incident response platform, or a complete SaaS discovery system covering every application used outside Google Workspace.

Application access restrictions and token revocations must follow the capabilities available through Google Workspace and the relevant integrations.

13. Best Practices for Third-Party App Governance

We recommend the following controls:

Maintain an Application Inventory

Document the applications used by employees, their business purpose, and their owners.

Review OAuth Permissions

Focus on applications requesting access to Gmail, Google Drive, and administrative services.

Apply Least Privilege

Grant only the level of access required by each application.

Restrict Unauthorized Applications

Configure Google Workspace API access controls according to the organization's security policy.

Include OAuth in Offboarding

Review and revoke unnecessary app authorizations when employees leave.

Investigate Unfamiliar Integrations

An unknown application should trigger a review of its purpose, permissions, and users.

Monitor Changes

Reassess permissions when an application changes its functionality or requests additional scopes.

Document Decisions

Keep a record of approved applications, exceptions, and risk assessments.

Review Regularly

Application governance is an ongoing activity rather than a one-time audit.

Frequently Asked Questions

How do I see third-party apps connected to Google Workspace?

Open the Google Admin console, navigate to Security > Access and data control > API controls, and open the third-party app access management interface. The information available depends on your administrative privileges and environment.

Can Google Workspace admins block third-party apps?

Yes. Google Workspace provides API access controls that allow administrators to restrict or block applications from accessing covered Google Workspace data.

How do I revoke OAuth access for a user?

Users can review their connected applications through Google Account settings. Administrators can also use supported Google Workspace security controls to review and revoke OAuth tokens, subject to privileges and available tools.

What is the difference between blocking an app and revoking its token?

Blocking an app applies an access policy that prevents covered API access. Revoking an OAuth token invalidates a particular authorization. The two actions are related but not identical.

Can an app access Google Drive without knowing the user's password?

Yes. An application authorized through OAuth can access the Google Drive resources permitted by its granted scopes without receiving the user's Google password.

Are Google Workspace Marketplace apps automatically safe?

No. Marketplace availability and application verification do not replace a security assessment of permissions, vendor practices, and business requirements.

Can a suspended employee still have OAuth app connections?

Application records or authorization history may remain visible. Whether effective access remains possible depends on account state, token validity, and policy enforcement. Administrators should verify and revoke unnecessary authorizations rather than rely on the visible record alone.

Can administrators require approval for new third-party applications?

Administrators can restrict API access and define which apps are approved or trusted. A fully automated approval workflow is not universally available for every integration and edition.

What are OAuth scopes?

OAuth scopes describe the permissions an application requests, such as access to Drive files, Gmail messages, or Calendar events.

What is Shadow IT in Google Workspace?

Shadow IT refers to applications and services used without adequate IT visibility or approval. It can include employee-authorized SaaS applications connected through Google OAuth.

Does revoking OAuth access delete data already collected by an app?

No. Revocation prevents further use of the affected authorization, but it does not automatically erase data previously copied or stored by the application.

How can MOZAYK Workspace help with third-party app audits?

MOZAYK Workspace provides a Shadow IT & SaaS module that helps administrators gain visibility into connected applications and review access-related risks as part of Google Workspace governance.

Conclusion

Third-party applications can provide significant productivity benefits, but they also introduce access and data protection risks.

For Google Workspace administrators, the key challenge is maintaining visibility into connected applications, understanding their permissions, and removing unnecessary access.

A reliable audit process should combine application inventory, OAuth scope review, access restrictions, token revocation, and employee offboarding controls.

Regular reviews are particularly important when employees frequently adopt new SaaS tools or when organizations handle sensitive business information.

MOZAYK Workspace helps simplify application governance through its Shadow IT & SaaS module and centralized Google Workspace administration features.

Improve Visibility Into Google Workspace Applications

Identify connected applications, review access-related information, and support your organization's Google Workspace security processes.

Explore MOZAYK Workspace and start your 30-day free trial.

See the Shadow IT module or start your free trial

Official Google Documentation

• Control which third-party and internal apps access Google Workspace data
• Manage connections between your Google Account and third-party apps
• Google Workspace Admin Help
• Google Account permissions and third-party access