OAuth allows users to grant third-party applications access to Google Workspace data without sharing their password. Depending on the authorization granted, an app may receive access that continues beyond the user’s initial session, including through refresh tokens that can obtain new access tokens.
That persistence can create risk when an application is no longer used, but its authorization remains in place. Over time, organizations can accumulate third-party connections that still have access to Workspace data even though the original business need has changed.
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
A significant OAuth governance challenge is access that was legitimately granted and later forgotten.
Consider a third-party marketing integration authorized for a short-term campaign. It may have been granted access to Gmail, Drive, Calendar, or another Workspace service. The project ends, and employees stop using the application, but the authorization may remain unless it is revoked or otherwise expires.
The same pattern can occur with project management tools, scheduling platforms, AI applications, browser-based services, and other SaaS products.
The security issue is not that every unused application is malicious. It is that access can outlive the business reason for granting it.
If the application is later compromised, or the organization no longer trusts the vendor, existing authorization can become an unnecessary path to company data.
That is why OAuth governance should include regular reviews of both active and inactive third-party applications.
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
Google Workspace gives admins native controls to review third-party applications and manage how they access organizational data.
In the Admin Console, navigate to Security > Access and data control > API controls > Manage App Access. From here, you can review apps that have accessed Google Workspace data, see which users are connected, examine requested services and OAuth scopes, and configure how apps can access Workspace data.
This gives admins a foundation for controlling third-party access. At enterprise scale, the challenge becomes identifying which apps and permissions deserve attention first, tracking whether access is still being used, and taking action consistently across the domain.
A practical OAuth 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.
Which OAuth scopes should Google Admins review?
OAuth scopes define what an application is allowed to do with a user’s Google Workspace data.
Not every scope represents the same level of access. An application requesting basic identity information presents a different risk from one that can access Gmail messages, Drive files, Calendar data, or other sensitive Workspace information.
When reviewing an application, ask:
- – What Workspace data can this app access?
- – Does it have read-only access or permission to modify data?
- – How many users have authorized it?
- – Does the app still have a legitimate business purpose?
- – Are the requested permissions proportionate to what the app actually needs?
The goal is not simply to find apps with broad permissions. It is to identify where the access granted no longer matches the business need.
An app approved for a short-term project, for example, may still retain access months later even though employees no longer use it.
Step 2: Revoke dormant access
Apps with no recent activity and access to sensitive Workspace data should be prioritized for review. If the app no longer has a legitimate business purpose, revoke its access. Organizations can define an inactivity threshold based on their own security and application governance policies.
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.
OAuth access is becoming part of AI governance
As organizations adopt AI tools and agents that connect to Google Workspace, OAuth governance is becoming part of a wider question: what applications and AI systems can act with a user’s access?
Third-party AI tools may request access to Workspace services through OAuth, making it increasingly important to understand which applications have been authorized, what scopes they hold, and whether that access is still appropriate.
For a deeper look at this shift, read Agentic AI Security in Google Workspace.
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 are no longer being used 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
1. What is an OAuth token in Google Workspace?
OAuth allows a third-party application to access Google Workspace services on behalf of a user without receiving the user’s password. The permissions available to the application depend on the OAuth scopes the user or administrator authorizes.
2. Why is unused OAuth access a security risk?
An application may retain authorization after employees stop actively using it. If the organization no longer needs that access, the application retains an unnecessary connection to organizational data. Regular reviews help admins identify applications whose permissions no longer match a legitimate business need.
3. What is OAuth consent phishing?
OAuth consent phishing attempts to persuade users to authorize a malicious application through a legitimate OAuth consent flow. Instead of stealing the user’s password, the attacker seeks permission to access data through the application based on the scopes the user approves.
4. How do you audit OAuth-connected apps in Google Workspace?
Admins can review third-party applications under Security > Access and data control > API controls > Manage App Access. From there, admins can review apps that have accessed Workspace data, connected users, requested services, and OAuth scopes. GAT+ adds domain-wide visibility and risk context to help admins prioritize connections for review.
5. Which OAuth scopes should Google Workspace admins review?
Pay particular attention to applications requesting access to sensitive Workspace data or permissions that allow them to modify information. Admins should assess what the application can access, how many users have authorized it, and whether those permissions are necessary for its current business purpose.
6. How do you revoke OAuth access in Google Workspace?
Google Workspace admins can use API controls to manage third-party application access. GAT+ can apply app policies across users, groups, and OUs, while GAT Flow can include token revocation as part of an offboarding workflow.
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.
