Controlling Cross-App Data Sprawl in Google Workspace
One of the most difficult challenges in third party risk management (TPRM) is how to effectively manage application sprawl.
It’s possible, but painful to allowlist apps at the operating system level using execution control tools. It’s possible, but painful to allowlist browser extensions using managed or isolated browsers.
It’s also painful to manage the ability of users to authorise third party applications to access data in sanctioned SaaS platforms, such as Microsoft 365 or Google Workspace.
For many years, the default configuration in productivity platforms was to allow users to provide their consent to allow third party apps to access data in their account using OAuth consent grants.
This was empowering for individual (consumer) users, and facilitated strong growth in these platform ecosystems. It wasn’t so rosy for the enterprise, however, which now had to contend with users sharing unbridled access to corporate-owned resources. The risks were exacerbated because the tools to manage OAuth content grants were gated by premium licenses.
OAuth Consent Phishing
As a result, legitimate OAuth apps have become a prime target for attackers and rogue OAuth apps have become a useful tool for phishing enterprise users.
In an OAuth Consent Phishing attack, social engineers create a pretext that convinces users to allow a third-party application to access data in their account.
Public examples of these attacks have impersonated trusted entities such as:
Email filtering software (e.g. “Please update your email security extension”)
Google Developer Support (e.g. “Your item is at risk of being removed from the Chrome web store. Please accept our policies to continue publishing your products”)
An internal HR team (e.g. a shared file with the words “July bonus” in the filename)
You can’t blame the user for these attacks. In these examples, developers of browser extensions and even security experts at the SANS Institute (yes, the guys that train cybersecurity professionals) were duped into allowing rogue apps to raid their inboxes, wikis and calendars. This is an attack that can trick just about anybody.
The risk is exacerbated in environments where an administrative user performs their administrative tasks and their general productivity work using the same account: one erroneous consent and they can easily give away the keys to the kingdom.
Tackling unsanctioned apps at Okta
A few months ago, concerns over OAuth consent grants resurfaced after Patrick Opet, Chief Information Security Officer at JP Morgan, wrote an open letter to third-party suppliers expressing his anxiety about the erosion of traditional enterprise boundaries.
His primary concern was integration patterns that enable users to create direct, often unchecked interactions between third-party services and firms’ sensitive internal resources.
We’ve had to tackle this internally at Okta. Our team has blocked thousands of attempts by corporate users to provide consent to OAuth applications to access data in their Google Workspace accounts.
The vast majority of these requests were for app scripts developed by Okta staff who wanted to extend the functionality of Google Sheets or Google Calendar. Okta is an organization that prides itself on employees being “builders and owners” with the technical skills to automate their way out of problems. So the key to a good security program is to find safe ways for them to experiment.
Okta Security tackled this problem internally by:
configuring our Workspace environment to deny user consent to add new applications by default,
making it as easy as possible for legitimate apps to be allowlisted, and
assigning ownership and monitoring activity in allowlisted applications.
If a user attempts to consent to an unsanctioned application, the request is denied (see image below). The user is presented with instructions on how to file a ticket to have the application reviewed by Okta’s Third Party Risk Management (TPRM) team. The process requires the user to provide a business justification for adding the application.

The TPRM team assesses the business case, whether the application was developed by an approved vendor, and if so, whether the scope of the integration is appropriate for the use case.
Often applications are only allowlisted after the scope of the integration is appropriately minimized, and a service account is configured to manage the integration.
If you need to tackle a backlog of integrated apps, Google Workspace includes administrative tools that allow administrators to filter app integrations according to whether they are verified, which users or groups can access them and the allowed scopes for the app.
The world needs cross-app access!
Okta Security was only able to manage what data stored in Google Workspace could be shared with other third party apps because Google built the required administrative controls and Okta was licensed to use them.
What about all the other apps? The average enterprise has 247 apps integrated in Okta, according to Okta’s Businesses at Work report. It’s naive to expect that all of those SaaS companies have the capability and resources to develop bespoke management capabilities to the degree Google can, or that enterprise CSOs have the resources to configure cross-app sharing in 200+ different consoles!
So ultimately, if we want to solve the problem of cross-app data sharing a scale, we believe these cross-application authorization flows need to be managed centrally by the CISO, using a centralized Identity solution, rather than within each individual application.
With this in mind, Okta recently proposed Cross-App Access, a method of securing agent-to-app and app-to-app access.
To learn more about securing app-to-app access, you can register to join our upcoming seminar.