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.
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 to review it all without breaking the tools people rely on.
| What You’ll Learn | Why It Matters | What It Helps You Avoid |
| What third-party app access means | How OAuth permissions work in plain terms | Treating a consent click as harmless |
| Finding connected apps | Where to see every app that already has access | Not knowing what is already connected |
| Access levels and restricted services | What each setting changes for apps and users | Breaking tools by flipping a switch blindly |
| Unconfigured apps and client IDs | How to set a default stance and manage specific apps | Open-ended access for apps nobody reviewed |
| Auditing and support | How to keep control over time | A one-time clean-up that goes stale |
What are third-party app permissions in Google Workspace, and why do they matter?
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.
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.
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.
How do you see which apps already have access to your data?
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: configured apps, 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.
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.
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.
What do Trusted, Limited, Specific Google data and Blocked actually mean?
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.
| Level | What the app can reach | Where it fits |
| Trusted | All Google services, including restricted ones | Vetted apps your business depends on |
| Limited | Only services you’ve left unrestricted | Apps that need basic access and nothing sensitive |
| Specific Google data | Only the data scopes an admin configures (where your console offers it) | Apps that need one narrow slice of data |
| Blocked | No Google service | Apps you’ve reviewed and rejected |
Myth vs. Fact
Myth: A Trusted app has been approved by Google.
Fact: 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.
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.
How do restricted and unrestricted Google services change what apps can do?
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.
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.
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:
- Open the accessed apps list and filter it by requested service, for example Gmail or Drive.
- Note which apps your teams genuinely use, and mark those Trusted first.
- Switch the service to Restricted during a quiet window, and tell people beforehand.
- Give it two days before drawing conclusions, since the accessed list updates up to 48 hours after a token is granted or revoked.
Skipping step two is how a Monday morning turns into a queue of “my add-on stopped working” tickets.
How should you handle apps you haven’t configured?
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.
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.
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.
Before vs. After
| A typical default setup | A deliberate setup | |
| Default for new apps | Whatever a user approves on the consent screen | Unconfigured apps blocked, or limited to Google sign-in only |
| Business-critical tools | Work only until a restriction is switched on | Explicitly trusted, so restrictions don’t break them |
| What users see when blocked | A confusing error | A custom message with a contact |
| Visibility | Discovered after an incident | Reviewed against a downloaded baseline |
How do you allow or block an app by OAuth client ID?
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.
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.
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.
How often should you audit app access, and what should the review cover?
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.
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:
- Apps requesting high-risk scopes in Gmail or Drive, and whether the business really needs them
- Apps used by one or two people, which are often experiments that never got cleaned up
- Apps with many users and no clear business owner
- Unverified apps asking for broad access
- Anything nobody on the team recognizes
Then close the loop with people. Tell users what the policy is, and give them a quick way to request an app rather than working around the block. A policy that people can’t live with gets bypassed, and a bypassed policy is worse than none.
When does it make sense to bring in a Workspace partner?
It makes sense when the inventory is bigger than your team can review, when restricting a service might break tools you depend on, or when something has already gone wrong. Each of those is cheaper to handle with someone who has seen the pattern before.
Admin control problems rarely announce themselves politely. When Upasana4u lost access to its suspended email accounts and admin credentials, we worked with Google’s support team to recover the IDs and re-establish admin control, which preserved 17 years of business continuity. In a different engagement, Kankatala’s work on securing business communication on Google Workspace shows the same discipline applied before an incident rather than after one. Codelattice is a Google Premier partner for Google Workspace, and our case studies page lays out more real projects with their real constraints.
30-Second Decision
- Do you know how many third-party apps currently have access to your organization’s Google data?
- Has anyone downloaded the accessed apps list and read the requested scopes?
- Have you checked which apps hold high-risk Gmail or Drive scopes?
- Do you have a deliberate default stance for unconfigured apps?
- Do users know who to contact when an app is blocked?
Two or more noes mean a review is overdue. It’s a good job for an afternoon, and an easier one with a second pair of eyes.
App access is easy to get wrong in both directions, too loose or too tight. As a Google Workspace partner, Codelattice offers a free consultation to review your current third-party app access and plan changes safely. We handle migration, onboarding and ongoing support, backed by a lightning-fast SLA and multi-language support. Write to askus@codelattice.com and tell us what you’re using.
