This is the GAT Labs for Enterprise website. Go to the GAT Labs for Education solutions here.

OAuth App Security: The Invisible Backdoor in Google Workspace

OAuth app security Google Workspace

See GAT Labs
in action

Table of Contents

An OAuth token is a persistent access credential that users grant to third-party applications when they connect those apps to their Google account. It allows the app to access Gmail, Drive, Calendar, or other Workspace services without handling the user’s password. The token remains active until someone explicitly revokes it, which rarely happens by default.

That persistence is the problem. Every token granted by a user in your domain is a live access path into your environment. Most of them are never reviewed after they are created.

OAuth abuse is now a primary enterprise attack vector

OAuth exploitation has become one of the dominant tactics used against cloud-based environments.

The 2025 Verizon Data Breach Investigations Report analyzed over 22,000 incidents and found that compromised credentials were the most common initial access vector, involved in 22 percent of confirmed breaches. Third-party involvement in breaches doubled year-over-year, rising from 15 to 30%. OAuth-connected third-party apps fall squarely in that category.

The attack model has shifted from stealing passwords to manipulating authorization. Rather than tricking a user into handing over credentials, attackers now trick them into granting access through a legitimate-looking OAuth consent screen. Once consent is given, the attacker holds a token with the exact permissions the user approved, and that token persists even if the user later changes their password or resets their MFA.

CISA and multiple threat intelligence teams have flagged OAuth consent phishing as a significant and growing attack pattern against enterprise cloud environments. In one documented campaign, attackers created thousands of malicious applications and used them to harvest persistent access tokens at scale across enterprise environments.

The key insight: OAuth attacks succeed because they use legitimate mechanisms. The token is not stolen; it is granted. Once it exists, it behaves like any other authorized connection in your domain.

The danger of dormant tokens

Most of the OAuth risk in a typical Google Workspace domain is not from active attacks. It is from access that was legitimately granted, then forgotten.

Think about a third-party marketing integration authorized for a campaign two years ago. It may have requested read, compose, send, and delete permissions across Gmail, plus full Drive access. The campaign ended. The integration was “disconnected.” But the OAuth token remains valid, sitting in your environment with every permission the user originally granted.

Research found that privileged dormant service accounts exist in over 70% of enterprise environments. The risk is not that an attacker needs to work hard to exploit them. The risk is that they barely need to work at all.

When the app developer’s infrastructure is breached, a third-party risk entirely outside your control, the attacker immediately inherits all the permissions your users originally granted. No password required. No MFA to bypass. The token does it all.

This is what makes dormant OAuth tokens so dangerous: they are legitimate credentials that persist without review, accumulate over time, and provide high-privilege access to core business data.

Shadow IT multiplies the exposure

Dormant tokens do not exist in isolation. They accumulate because shadow IT is constant.

Users connect apps throughout the day: productivity tools, AI assistants, project integrations, and scheduling utilities. Most of these connections happen without IT review. Each one creates an OAuth token. Over time, a domain of several hundred users can accumulate thousands of active and dormant tokens across hundreds of applications, many of which no one on the IT team knows exist.

This is why third-party app integrations are consistently identified as a leading source of data breaches in cloud environments. The attack surface is not one bad decision — it is the aggregation of thousands of small decisions made by individual users over years.

For a full picture of how shadow IT creates this exposure in Google Workspace specifically, see Shadow IT in Google Workspace: What the Admin Console Does Not Tell You.

How to audit and control OAuth tokens in Google Workspace

The Admin Console provides a starting point. Navigate to Security > Access and data control > API controls > App Access Control to view connected applications.

However, it has limitations. It does not clearly surface permission scope in a risk-based way, lacks visibility into app usage at scale, and does not support bulk remediation or policy enforcement across users.

A practical audit and control framework has four steps.

Step 1: Get a complete picture

Pull all third-party apps connected to your domain. For each app, review:

  • – Permission scope (what data it can access)
  • – Number of users who granted access
  • – Last activity or usage

Apps with no recent activity should be prioritized for review.

GAT+ provides this view with a scope risk score for each app, helping you identify high-risk connections faster and at scale.

Step 2: Revoke dormant access

Any app inactive for 60 to 90 days with sensitive permissions, such as Gmail or Drive access, should be reviewed and removed unless there is a clear business need.

GAT+ supports bulk revocation across users, groups, and OUs.
You can also configure policies to flag or trigger actions on inactive connections, reducing reliance on manual reviews.

Step 3: Set domain-wide app policies

Move from reactive cleanup to proactive control.

Define:

  • – Trusted apps
  • – Restricted or high-risk apps

When a user attempts to authorize a restricted app, GAT+ can automatically block or revoke access based on policy, preventing ongoing exposure.

Step 4: Monitor new authorizations

Audits show what already exists. Monitoring helps you catch new risks early.

Configure alerts in GAT+ to flag new app connections based on scope risk. This allows you to review and respond quickly instead of discovering risky access months later.

Offboarding: don’t overlook OAuth

When a user leaves, all OAuth access should be revoked as part of offboarding.

GAT Flow can automate this step, helping ensure no third-party access persists after the account is closed.

Browser extensions: the risk most admins are not tracking

OAuth-connected apps are usually the most visible risk in Google Workspace. Browser extensions are often the least visible.

When a user installs a Chrome extension, they grant permissions at the browser level rather than through APIs. Some extensions request access to read and change data across websites, which can include content viewed inside Google Workspace.

Unlike OAuth apps, this activity is not fully surfaced in the Admin Console.

GAT Shield provides visibility into extensions across your domain, including:

  • – Permission scope
  • – Install date
  • – Number of users
  • – Risk score based on access level

This allows admins to identify high-risk extensions and take action, such as blocking or restricting them, without relying solely on traditional device management controls.

For a deeper breakdown, see the Chrome extension risk assessment guide.

The connection to Google Workspace phishing

OAuth abuse and phishing are increasingly the same attack. Attackers do not need to steal credentials when they can have users voluntarily grant access through a consent screen.

A user receives an email that appears to come from a legitimate service, a document sharing platform, a scheduling tool, or a finance integration. They click a link and are presented with a real Google OAuth consent screen asking for Drive or Gmail permissions. The application is malicious, but the consent mechanism is legitimate. If the user approves, the attacker has persistent access.

This is why reviewing OAuth-connected apps is not just a housekeeping task; it is an active threat defense. For more on how phishing intersects with Google Workspace security, see Phishing Threats in Google Workspace: What Google Admins Should Know.

What good OAuth governance looks like

An organization with strong OAuth governance has answers to these questions at any time:

  • – Which third-party apps are connected to our domain, and what can each one do?
  • – Which apps have not been used in the last 90 days but still hold active permissions?
  • – Which apps were connected by users without IT review?
  • – What happens when a user tries to connect a high-risk app?
  • – Do all departing employees have their app access revoked before or at offboarding?

If any of these cannot be answered without a manual investigation, the OAuth inventory needs a control layer.


FAQ

What is an OAuth token in Google Workspace?
An OAuth token allows a third-party app to access a user’s Google Workspace data, such as Gmail, Drive, or Calendar, without using a password. When a user approves an app, Google issues the token, and it remains active until someone revokes it. Password changes or MFA resets do not affect the token.

Why are dormant OAuth tokens a security risk?
Dormant tokens continue to grant access even when users no longer use the app. If attackers compromise the application, they gain the same permissions the user originally approved. This creates a persistent and often unmonitored access path to sensitive data.

What is OAuth consent phishing?
OAuth consent phishing tricks users into approving a malicious app through a legitimate-looking consent screen. Once the user grants access, the attacker receives a valid token with real permissions. The access remains active even if the user later changes their password.

How do you audit OAuth-connected apps in Google Workspace?
Admins can review connected apps in the Admin Console under Security > API Controls > App Access Control. This view provides a basic list of applications. Tools like GAT+ give admins deeper visibility into permission scope, usage, and user impact, and support bulk analysis across the domain.

How do you revoke OAuth tokens in Google Workspace?
Admins can revoke tokens individually in the Admin Console or remove them in bulk using GAT+. GAT Flow can automatically revoke all tokens linked to a user during offboarding, so no third-party access remains after the account is closed.

Insights That Matter. In Your Inbox.

Join our newsletter for practical tips on managing, securing, and getting the most out of Google Workspace, designed with Admins and IT teams in mind.

Subscribe to GAT Labs Newsletter