Audit Marketplace Apps With Workspace Data Access

How many third-party apps can read your company's emails right now? If you cannot answer that question within thirty seconds, you have an audit problem. And you are not alone. Research consistently shows that the average organisation has hundreds of OAuth-connected apps across its user base, most of which were never reviewed or approved by anyone in IT.

Every time someone on your team installs a Google Workspace Marketplace app, they grant it a set of permissions to your organisation's data. That free meeting scheduler reads every calendar. That productivity extension scans every email. That document formatting tool has full access to Drive. The permissions persist until someone explicitly revokes them, and most organisations never do.

For Australian SMBs, this is both a security risk and a compliance liability. Under the Privacy Act 1988 and the Australian Privacy Principles, your business must take reasonable steps to protect personal information from unauthorised access. Having dozens of unreviewed third-party apps with broad access to your Workspace data is difficult to justify as "reasonable" in any compliance assessment. The Australian Signals Directorate's Essential Eight framework reinforces this through its application control strategy: you should know and control what software interacts with your data.

This guide walks you through a complete audit of Marketplace app access in your Google Workspace environment. You will learn how OAuth permissions work, how to find every connected app at both the domain and user level, how to assess the risk each one presents, and how to build a governance policy that prevents the problem from recurring.

What this guide covers:
- How OAuth permissions and scopes grant apps access to your data
- Finding all connected apps using the Admin Console
- Reviewing individual user app access
- A risk assessment framework for evaluating each app
- Creating an app governance policy for ongoing protection
- Security tools that can automate the audit process

Understanding OAuth Permissions and Scopes

Before you can audit app access, you need to understand the mechanism that grants it. When a user installs a Marketplace app or connects a third-party service to their Google account, they go through an OAuth consent flow. The app presents a list of permissions it wants, the user clicks "Allow," and Google issues an OAuth token that grants the app ongoing access to the specified data.

What Scopes Mean in Practice

OAuth scopes are the specific permissions attached to each token. They range from minimal to dangerously broad:

• Profile and email (low risk): The app can see your name and email address. This is the minimum scope for Google Sign-In and is generally harmless.
• Read-only calendar (moderate risk): The app can see every event on your calendar, including attendee lists, meeting links, and notes. This could expose internal meeting schedules and client appointment details.
• Read email messages (high risk): The app can read the full content of every email in a user's inbox, including attachments. Financial data, contracts, personal information, and passwords sent via email are all exposed.
• Full Drive access (critical risk): The app can read, create, modify, and delete every file the user can access, including files in Shared Drives. This is the broadest data access scope available.
• Admin SDK (critical risk): The app can manage users, groups, organisational units, and domain settings. This scope should only ever be granted to tools you explicitly trust with administrative control.

Why Users Grant Permissions Without Thinking

The OAuth consent screen is designed to be quick. Users see a popup, glance at the app name, and click "Allow" because they want to get back to work. Google has improved the consent screen over the years to make permissions more visible, but most users still do not read scope descriptions carefully. They treat it like a terms-of-service checkbox: an obstacle to click through, not a security decision to evaluate.

This is not a failure of your staff. It is a design problem compounded by habit. The solution is not training alone; it is controls. You need visibility into what has been granted and the ability to revoke or prevent grants that exceed your risk tolerance.

The Persistence Problem

OAuth tokens do not expire when a user stops using an app. If someone installed a Chrome extension six months ago, tried it once, and forgot about it, the token is still active. The app still has the same access it had on day one. Over time, your organisation accumulates a growing backlog of active permissions to apps that no one is using, maintained by no one, and monitored by no one.

Finding Connected Apps in the Admin Console

Google Workspace provides several views in the Admin Console for discovering what apps are connected to your domain. A thorough audit uses all of them.

View 1: API Controls Dashboard

This is your primary dashboard for app visibility at the domain level.

1. Sign in to the Google Admin console at admin.google.com with a Super Admin or Security Admin account.
2. Navigate to Security > API controls > App access control.
3. Click Manage third-party app access. This screen lists every app that has been configured with a trust level (Trusted, Limited, or Blocked) in your domain.

This view shows you what you have already configured, but it does not show you everything that is actually connected. For that, you need the next view.

View 2: Third-Party App Access Overview

1. Still in Security > API controls, look for the Third-party app access overview panel.
2. This provides a summary of how many apps have been accessed by users in your domain, broken down by trust status: configured apps, apps accessing data, and apps with risky access.
3. Click into the details to see the full list of apps, including those that users have connected but that you have not yet configured.

Pay close attention to the "Apps accessing data" count. If this number is significantly higher than your "Configured apps" count, you have a significant audit gap.

View 3: Token Log Events (Audit Log)

The token log gives you the most granular view of OAuth activity.

1. Navigate to Reporting > Audit and investigation > Token log events.
2. Set the date range. For your first audit, go back at least 90 days. For ongoing reviews, 30 days is sufficient.
3. Filter by event type to focus on Authorize events (new grants) and Revoke events.
4. Review each entry. The log shows the user, the app name, the client ID, and the scopes that were granted.

Export this data to a Google Sheet for analysis. You will want to sort by scope to identify the highest-risk grants and by app name to see how widely each app is used across your organisation.

View 4: Security Investigation Tool

For organisations on Business Plus or Enterprise plans, the Security Investigation Tool provides more advanced querying.

1. Navigate to Security > Investigation tool.
2. Select OAuth log events as the data source.
3. Build queries to filter by specific scopes (e.g., all apps with Gmail read access), specific users, or specific time periods.
4. Save useful queries for reuse in future audits.

Reviewing Individual User App Access

The domain-level views show you the big picture, but you also need to review access at the individual user level. This is especially important for users in high-risk roles: finance, HR, legal, and anyone with admin privileges.

Admin Console User-Level Review

1. Navigate to Directory > Users in the Admin Console.
2. Click on a specific user's name.
3. Select Security from the left panel.
4. Scroll to the Connected applications or Third-party apps section. This shows every app that this user has granted OAuth access to, along with the scopes.
5. You can revoke access for any app directly from this view by clicking the app and selecting Remove access.

Prioritise High-Risk Users

You do not need to review every user's app connections in your first audit. Start with these categories:

• Super Admins and admin role holders: Any app connected to an admin account has elevated risk because the account itself has elevated privileges.
• Finance and accounting staff: These users handle sensitive financial data, bank details, Tax File Numbers, and payment information. Apps connected to their accounts can access this data.
• HR and legal staff: These users handle employee personal information, contracts, and confidential legal communications.
• Executive team: C-suite and leadership accounts are high-value targets and often have access to the most sensitive organisational data.

Bulk Export for Analysis

For organisations with more than 20 users, reviewing accounts one by one is impractical. Use the Reports API or Google Apps Script to extract connected app data across all users. Alternatively, the third-party tools covered in the affiliate section below can automate this discovery process.

Risk Assessment Framework

Once you have a complete list of connected apps and their scopes, you need a systematic way to assess the risk each one presents. The following framework gives you a repeatable process.

Risk Scoring Criteria

Evaluate each app against five criteria and assign a risk level (Low, Medium, High, Critical) for each:

1. Scope Breadth
- Low: Profile and basic sign-in only
- Medium: Read-only access to a single service (e.g., Calendar read)
- High: Read/write access to a single service, or read-only access to multiple services
- Critical: Full access to Gmail, Drive, or Admin SDK

2. Publisher Reputation
- Low: Well-known, publicly traded company (e.g., Zoom, Slack, Atlassian)
- Medium: Established SaaS company with a clear website and privacy policy
- High: Small or unknown developer with limited web presence
- Critical: No identifiable publisher, or publisher with a history of security incidents

3. User Count Within Your Organisation
- Low: Used by more than 50% of your staff (indicates an established business tool)
- Medium: Used by a specific team (5-50% of staff) for a legitimate business purpose
- High: Used by 2-5 users with unclear business justification
- Critical: Used by a single user, especially if the user cannot explain why they installed it

4. Data Sensitivity
- Low: The app only accesses non-sensitive data (e.g., public calendar availability)
- Medium: The app accesses internal business data (documents, spreadsheets)
- High: The app accesses data containing personal information, financial records, or client data
- Critical: The app accesses data subject to regulatory obligations (Privacy Act, financial regulations)

5. Last Active Date
- Low: Used within the last 30 days
- Medium: Used within the last 90 days
- High: Not used in 90 to 180 days
- Critical: Not used in over 180 days but still holding active permissions

Making Decisions

After scoring, take action based on the overall risk profile:

• Mostly Low scores: Approve the app and add it to your trusted list. Review annually.
• Mixed Low and Medium: Approve with conditions. Set the app to Limited access rather than Trusted, and review quarterly.
• Any High scores: Investigate further before approving. Contact the publisher for security documentation. Consider whether an approved alternative exists.
• Any Critical scores: Revoke access immediately and block the app. Notify the affected users and provide an approved alternative if one exists. If the app is critical to business operations, escalate to leadership before re-granting access with documented risk acceptance.

Document Everything

Maintain a risk register in a Google Sheet with the following columns: App Name, Client ID, Publisher, Scopes Requested, User Count, Risk Score, Decision (Approved/Blocked/Under Review), Decision Date, Reviewer, and Notes. This register becomes your audit trail for compliance purposes and your reference for future reviews.

Creating an App Governance Policy

An audit is a point-in-time exercise. Without a governance policy, you will be back in the same position in six months. Here is how to build a sustainable policy for managing Marketplace app access.

Set the Default to Restricted

The single most impactful change you can make is changing the default policy for unconfigured third-party apps.

1. Navigate to Security > API controls > App access control > Settings.
2. Under Unconfigured third-party apps, change the default from the open setting to either:
3. Allow users to access only third-party apps that request basic sign-in info (recommended for most SMBs): This allows low-risk apps while blocking anything that requests access to Gmail, Drive, Calendar, or other data.
4. Don't allow users to access any third-party apps (for strict compliance environments): This blocks everything unless explicitly approved.

Mark Sensitive Services as Restricted

For an additional layer of protection, mark your most sensitive Google services as Restricted.

1. In Security > API controls > App access control, navigate to the Google services section.
2. Set Gmail, Google Drive, and the Admin SDK to Restricted.
3. This means only apps you have explicitly set to Trusted can access these services. Even apps with Limited access are blocked from restricted services.

Establish an Approval Workflow

Create a clear, documented process for employees to request new apps:

1. Request mechanism: Set up a Google Form or a dedicated email alias (e.g., app-requests@yourdomain.com.au) where employees can submit requests. Capture the app name, business purpose, the requesting user, and any urgency notes.
2. Evaluation timeline: Commit to a 48-business-hour response time. If approvals take too long, users will find workarounds.
3. Evaluation checklist: Use the risk assessment framework above to evaluate each request. Check the publisher, the requested scopes, alternative approved tools, and any security certifications (SOC 2, ISO 27001).
4. Decision and communication: Approve, deny, or request more information. Communicate the decision back to the requester with a brief explanation.

Schedule Recurring Audits

Build the following review cadence into your IT calendar:

• Monthly: Review the token log for new OAuth grants. Check the Alert Centre for any flagged app activity.
• Quarterly: Run the full audit process described in this guide. Review your approved app list for apps that are no longer in use. Remove trust for any decommissioned tools.
• Annually: Review your entire governance policy. Update the risk assessment framework based on any incidents or near-misses. Brief your team on OAuth security awareness.

Handle Employee Departures

Add OAuth token revocation to your employee offboarding checklist. When someone leaves:

1. Navigate to their user account in Directory > Users.
2. Open their Security settings.
3. Revoke all third-party app connections before suspending or deleting the account.

Tokens granted by a former employee remain active until explicitly revoked. A departed employee's connected apps can still access your organisation's data through their lingering OAuth grants.

Affiliate & Partner Programs

Running a thorough app audit is significantly easier with the right tools and platform tier. Here are resources worth considering:

• Google Workspace Referral Program: https://referworkspace.app.goo.gl/ -- Business Plus and Enterprise plans provide the full Security Investigation Tool, advanced API controls, and detailed audit logs needed for comprehensive app auditing. If you are on Business Starter and finding the Admin Console views limited, this is why.
• DoControl: A SaaS security platform that provides automated discovery and monitoring of every OAuth-connected application across your Google Workspace environment. DoControl maps out data flows between third-party apps and your Workspace, identifies over-permissioned connections, and can automatically remediate risky grants based on policies you define. Particularly useful for organisations with more than 50 users where manual auditing becomes impractical.
• Spin.AI: Offers automated risk assessment for third-party apps connected to Google Workspace. Their risk scoring engine evaluates OAuth scopes, developer reputation, data access patterns, and historical behaviour to assign each app a risk score. Spin.AI can flag high-risk apps before they cause problems and provides continuous monitoring rather than point-in-time audits.
• Nudge Security: Takes a different approach by discovering every SaaS application your employees are using, including those connected via OAuth, SSO, and direct sign-up. Nudge Security maps your full SaaS attack surface and provides automated nudges to employees when they connect risky applications. Especially relevant for Australian SMBs that want visibility across their entire SaaS footprint, not just Google Workspace.

Wrapping Up

Most Australian SMBs have more third-party apps connected to their Google Workspace data than they realise. The apps got there through individual employee decisions, each one reasonable in isolation, that collectively created an unmonitored web of data access across your organisation. The audit process in this guide gives you the tools to untangle that web.

Start with the Admin Console views. Pull the token log, review the API controls dashboard, and check the connected apps for your highest-risk users. Export the data, run it through the risk assessment framework, and make decisions: approve, limit, or block each app based on its risk profile. Then change your default policy so that new apps cannot connect without your knowledge.

The first audit is the hardest because you are building the baseline. Every subsequent audit is faster because you are only reviewing changes since the last one. Build the habit of monthly token log reviews and quarterly full audits, and you will maintain visibility without it becoming a burden.

Your employees installed those apps to be more productive, and most of the apps are probably fine. The point of an audit is not to block everything. It is to know what is there, confirm that it belongs, and remove what does not. That is the difference between a managed environment and a hopeful one.

Need help with your cloud migration? Contact our team for a free consultation.