{"id":8468,"date":"2026-11-02T14:05:25","date_gmt":"2026-11-02T08:35:25","guid":{"rendered":"https:\/\/www.codelattice.com\/blog\/?p=8468"},"modified":"2026-11-02T14:05:25","modified_gmt":"2026-11-02T08:35:25","slug":"third-party-app-access-in-google-workspace-how-to-control-which-apps-see-your-data","status":"publish","type":"post","link":"https:\/\/www.codelattice.com\/blog\/third-party-app-access-in-google-workspace-how-to-control-which-apps-see-your-data\/","title":{"rendered":"Third-Party App Access in Google Workspace: How to Control Which Apps See Your Data"},"content":{"rendered":"

Third-party app access in Google Workspace is the control that decides which outside apps can read or change your organization’s Google data, such as Gmail, Drive and Calendar. Admins manage it in the Admin console under API controls by marking each app as Trusted, Limited or Blocked and by restricting sensitive Google services.<\/span><\/p>\n

It’s easy to leave all of this on its defaults, because nothing visibly breaks until an app does something nobody expected. This guide walks through the controls as they work today: how to see which apps already have access, what each access level does, what happens when you restrict a service, and how t<\/span>o review it all without breaking the tools people rely on.<\/span><\/p>\n\n\n\n\n\n\n\n\n
What You’ll Learn<\/b><\/td>\nWhy It Matters<\/b><\/td>\nWhat It Helps You Avoid<\/b><\/td>\n<\/tr>\n
What third-party app access means<\/span><\/td>\nHow OAuth permissions work in plain terms<\/span><\/td>\nTreating a consent click as harmless<\/span><\/td>\n<\/tr>\n
Finding connected apps<\/span><\/td>\nWhere to see every app that already has access<\/span><\/td>\nNot knowing what is already connected<\/span><\/td>\n<\/tr>\n
Access levels and restricted services<\/span><\/td>\nWhat each setting changes for apps and users<\/span><\/td>\nBreaking tools by flipping a switch blindly<\/span><\/td>\n<\/tr>\n
Unconfigured apps and client IDs<\/span><\/td>\nHow to set a default stance and manage specific apps<\/span><\/td>\nOpen-ended access for apps nobody reviewed<\/span><\/td>\n<\/tr>\n
Auditing and support<\/span><\/td>\nHow to keep control over time<\/span><\/td>\nA one-time clean-up that goes stale<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

What are third-party app permissions in Google Workspace, and why do they matter?<\/h2>\n

A third-party app permission is the access an outside app receives to a user’s Google data after the user signs in with Google or approves a consent prompt. That access is defined by OAuth 2.0 scopes, which describe exactly what the app may do: read email, see calendar events, edit files and so on.<\/span><\/p>\n

Consider what the moment looks like to an employee. A scheduling tool, a PDF editor, a mail-merge add-on. One click on Allow, and the app can reach whatever the scope covers. The Admin console lets you decide which apps get that reach and which don’t, but only if someone uses it.<\/span><\/p>\n

Google sorts apps into three types: Google-owned, internal (apps your own organization builds) and third-party (everything else). This guide covers third-party apps. Admin roles and sharing settings are separate topics and aren’t covered here.<\/em><\/strong><\/p>\n

How do you see which apps already have access to your data?<\/h2>\n

In the Admin console, go to Menu, then Security, then Access and data control, then API controls, and open Manage Third-Party App Access. You need the Service Settings administrator privilege. The page splits apps into two lists:<\/span> configured apps<\/strong><\/span><\/a>, which have an access policy (Trusted, Limited or Blocked), and accessed apps, which are third-party apps your users have actually used to reach Google data.<\/span><\/p>\n

That split trips people up. If you’ve never trusted or blocked an app, the configured list reads zero, which says nothing about how many apps are connected. The accessed list is where the real picture lives. For each app it shows the number of users and the Google services it requests, and clicking through reveals the OAuth client ID, privacy policy, support details and the full list of scopes. Expect a 24 to 48 hour delay before a newly authorized app appears.<\/span><\/p>\n

Two habits make the list useful. First, download it. The CSV export includes columns the table doesn’t display, such as requested services and API scopes, so it makes a good baseline to compare against next month. Second, read the verified status with care. Verified means Google reviewed the app against certain policies, and many well-known apps aren’t verified in this way. Treat the badge as one input among several.<\/span><\/p>\n

What do Trusted, Limited, Specific Google data and Blocked actually mean?<\/h2>\n

Google offers three core access levels for a third-party app. Trusted allows access to every Google service, including restricted ones. Limited allows access only to services you’ve left unrestricted. Blocked denies access to every Google service. Some consoles also show a fourth option, Specific Google data, for allowing an app only the data scopes an admin configures.<\/span><\/p>\n\n\n\n\n\n\n\n
Level<\/b><\/td>\nWhat the app can reach<\/b><\/td>\nWhere it fits<\/b><\/td>\n<\/tr>\n
Trusted<\/b><\/td>\nAll Google services, including restricted ones<\/span><\/td>\nVetted apps your business depends on<\/span><\/td>\n<\/tr>\n
Limited<\/b><\/td>\nOnly services you’ve left unrestricted<\/span><\/td>\nApps that need basic access and nothing sensitive<\/span><\/td>\n<\/tr>\n
Specific Google data<\/b><\/td>\nOnly the data scopes an admin configures (where your console offers it)<\/span><\/td>\nApps that need one narrow slice of data<\/span><\/td>\n<\/tr>\n
Blocked<\/b><\/td>\nNo Google service<\/span><\/td>\nApps you’ve reviewed and rejected<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Myth vs. Fact<\/h3>\n

Myth:<\/strong> A Trusted app has been approved by Google.<\/p>\n

Fact:<\/strong> Trusted is a decision you make as the admin. Google’s own review shows separately as a Google-verified badge, and many well-known apps don’t carry one.<\/p>\n

A few details are worth knowing before you start changing settings. Trusting an app overrides a service restriction, which is the whole point of the setting. Google-owned apps, such as the Chrome browser, are trusted automatically and can’t be configured. And blocking beats allowlisting: if you allowlist an app for devices and also block it under API controls, the block wins.<\/span><\/p>\n

How do restricted and unrestricted Google services change what apps can do?<\/h2>\n

Each Google service, such as Gmail, Drive or Calendar, can be set to Restricted or Unrestricted. In a restricted service, only apps you’ve trusted can reach the data, and Limited apps are turned away. In an unrestricted one, Limited apps can get in as well. Google’s own example is Calendar: set it to Restricted and a Limited app can’t read it.<\/span><\/p>\n

For Gmail and Drive you can go a step further and restrict a predefined list of high-risk scopes, the ones that do things like send mail or delete files. There’s an optional checkbox that lets users grant untrusted apps access to scopes outside that high-risk list, for instance access to files a user picks in Drive. Restricting Drive also restricts the Google Forms API, which catches people out.<\/span><\/p>\n

Here’s the part to read twice. If you change a service to Restricted, previously installed apps you haven’t trusted stop working and their tokens are revoked. Nobody gets a warning. So the order matters:<\/em><\/strong><\/p>\n

    \n
  1. Open the accessed apps list and filter it by requested service, for example Gmail or Drive.<\/em><\/strong><\/li>\n
  2. Note which apps your teams genuinely use, and mark those Trusted first.<\/em><\/strong><\/li>\n
  3. Switch the service to Restricted during a quiet window, and tell people beforehand.<\/em><\/strong><\/li>\n
  4. Give it two days before drawing conclusions, since the accessed list updates up to 48 hours after a token is granted or revoked.<\/em><\/strong><\/li>\n<\/ol>\n

    Skipping step two is how a Monday morning turns into a queue of “my add-on stopped working” tickets.<\/em><\/strong><\/p>\n

    How should you handle apps you haven’t configured?<\/h2>\n

    Unconfigured apps are third-party apps you haven’t marked Trusted, Limited, Specific Google data or Blocked, and you set the default stance for them under API controls, Settings, Unconfigured third-party apps. Most organizations end up choosing between two stances, depending on how tight they want things.<\/span><\/p>\n

    The strict option, “Don’t allow users to access any third-party apps,” blocks all OAuth scopes for unconfigured apps, including sign-in scopes. Users can then no longer use Sign in with Google on third-party sites and apps, though anything you’ve set to Trusted or Limited keeps working. The gentler option allows unconfigured apps that only ask for Google sign-in information, such as an email address, and nothing else. Education editions word and offer these options differently, so check your edition. If you build your own internal apps, there’s also a Trust internal apps checkbox, so you don’t have to trust them one by one.<\/span><\/p>\n

    Don’t skip the user message setting on the same Settings card. When an unauthorized app is blocked, people see whatever message you’ve written. “Contact IT at this address to request approval” turns a dead end into a process.<\/span><\/p>\n

    Before vs. After<\/h3>\n\n\n\n\n\n\n\n
    <\/td>\nA typical default setup<\/b><\/td>\nA deliberate setup<\/b><\/td>\n<\/tr>\n
    Default for new apps<\/span><\/td>\nWhatever a user approves on the consent screen<\/span><\/td>\nUnconfigured apps blocked, or limited to Google sign-in only<\/span><\/td>\n<\/tr>\n
    Business-critical tools<\/span><\/td>\nWork only until a restriction is switched on<\/span><\/td>\nExplicitly trusted, so restrictions don’t break them<\/span><\/td>\n<\/tr>\n
    What users see when blocked<\/span><\/td>\nA confusing error<\/span><\/td>\nA custom message with a contact<\/span><\/td>\n<\/tr>\n
    Visibility<\/span><\/td>\nDiscovered after an incident<\/span><\/td>\nReviewed against a downloaded baseline<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    How do you allow or block an app by OAuth client ID?<\/h2>\n

    Go to API controls, open Manage Third-Party App Access, and choose Add app under Configured apps. Search by OAuth app name or client ID, or choose Android or iOS, select the app, tick the client IDs you want to configure, pick Trusted or Blocked and click Configure. The client ID identifies a specific app registration, which makes it a more precise handle than a display name. Google also offers a bulk option for adding and configuring many apps at once.<\/span><\/p>\n

    Policies can be applied by an organizational unit, which lets you trust a tool for one department without opening it to everyone. One quirk to remember: if you apply a policy to an organizational unit and then apply a different policy to the whole organization, the unit keeps its original policy.<\/span><\/p>\n

    Marketplace apps sit on a separate track. Users are normally prompted to consent when they add an app, but for approved Marketplace apps an admin can bypass the consent screen through domain installation. Marketplace installs also have their own settings, including whether users can install apps at all and an allowlist. If your goal is a tight app policy, review both tracks, because closing one leaves the other open.<\/span><\/p>\n

    How often should you audit app access, and what should the review cover?<\/h2>\n

    A monthly quick pass and a quarterly full review is a reasonable rhythm for most organizations. The accessed apps list is retrospective, since it reflects tokens that were already granted, so the value of an audit is catching what’s new before it becomes normal.<\/span><\/p>\n

    For the monthly pass, download the accessed apps list and compare it with last month’s file. Look at what appeared. For the quarterly review, go deeper:<\/span><\/p>\n