Continue with Google is two decisions

Nobody designs their third-party access model. It arrives one consent screen at a time.

Someone signs up for a SaaS product with their work account. A scheduling tool asks for Calendar. A browser extension asks for Drive. A reporting product asks for Gmail. Every one of those approvals was reasonable to the person who clicked it, and three years later the environment cannot answer a simple question: which applications should still be able to reach company data?

The instinct is to lock OAuth down. That is the wrong control. The useful control is noticing that Continue with Google is two requests wearing one button.

The first is an identity decision and it should be easy. The second is a data decision and it should not be delegated to whoever is signing up for a trial.

Most environments treat these as one thing, which is why the two common postures are both bad. Allow everything, and the data boundary expands every time someone discovers a new tool. Block everything, and you break services that use Google purely to identify people, while teaching users to sign up with personal addresses instead. Neither is necessary.

The inventory comes first

Do not open the policy settings yet.

Export the applications that have accessed the tenant, with the user count, the services touched and the scopes requested. OAuth log events can help show which grants are still producing activity and which have gone quiet. Pair that with the app inventory and user counts: absence of recent activity is a reason to investigate an integration, not proof that it is safe to remove.

The application name is never enough. A tool with one user might be an abandoned experiment, or it might be the integration that moves every closed deal into the CRM. A tool with fifty users might be load-bearing, or it might just have been easy to sign up for.

So each entry needs a business answer, not only a technical one:

• Who uses it, and does anyone still own it?
• Is Google being used only to sign in?
• Which services does it actually need, and at which scope?
• Do the permissions match the stated purpose?
• What breaks the day the grant is removed?

This is where the useful discoveries are. Applications nobody recognizes. Duplicates from a migration. Two competing tools doing the same job. An integration reading an entire Drive to produce a weekly report on one folder.

Look where users never clicked

A consent-screen inventory only covers access that a user granted. It is not the whole surface.

Domain-wide delegation is the one to review separately. A service account granted domain-wide delegation can impersonate users without each user consenting, within the OAuth scopes an administrator authorised and the permissions of the impersonated user. That makes it one of the most privileged access paths in the environment and one that deserves its own inventory. Every delegated client ID should have a named owner, a documented purpose and a scope list that someone has actually read.

Then the rest of the quiet population: internal apps built on your own Cloud projects, Marketplace apps installed org-wide rather than by individuals, Apps Script projects running on someone's authorization, and OAuth clients that outlived the person who created them.

If the review only covers user-consented third-party apps, it can miss some of the most privileged access paths.

Four buckets, then enforcement

Reduce the inventory to four operating groups. These are business decisions first; Google's access settings are the enforcement mechanism.

Sign-in only. Needs the corporate identity, nothing else. Should be frictionless.

Specific data access. Has a legitimate reason to touch one service. Grant it the scopes it needs and nothing adjacent.

Broad trusted integration. Genuinely requires wide access because of what it does. There should be very few of these, each documented and owned. In Google's access model, Trusted permits access to restricted as well as unrestricted Workspace services, so the label is a real access decision, not a convenience. Where Specific Google data is sufficient, prefer the narrower scope.

Unknown or abandoned. Block, and revoke the tokens.

"We use this app" is not the same statement as "this app should be trusted." Trust describes the access an integration needs. It is not a comment on how familiar the logo is.

Then change the default

Cleaning the list solves yesterday. The default setting decides what tomorrow looks like.

Configure unconfigured apps so that basic Google sign-in can continue without automatically granting access to Workspace data. Anything asking for more should require an explicit decision.

Pair that with the access-request flow, so a blocked user gets a route to an answer instead of a dead end and a workaround. Requests arriving in the admin console are also a useful signal of what the business is actually trying to adopt.

The result is an environment that can keep adopting SaaS at the speed the business wants, without widening its data boundary every time it does.

Restrict the services last

Sequencing is the part people get wrong.

Restrict Gmail, Drive and Calendar before reviewing the applications that depend on them, and integrations that have not been configured with an access level that permits the services and scopes they require can stop working. Revoking token access can make the effect immediate.

An outage will certainly tell you which systems depended on OAuth. It is an expensive way to build an inventory.

Inventory. Review. Configure the applications you intend to keep. Then mark the sensitive services restricted, so access depends on decisions you have deliberately made rather than on a consent screen nobody remembers.

The integrations you configured correctly for the access they require should keep working. Everything else stops inheriting access simply because somebody clicked Allow years ago.

Two details are worth testing rather than assuming.

Scope granularity is where much of the risk reduction lives: reading a user-selected file is not the same as reading an entire Drive, viewing free/busy is not modifying calendars, and reading mail is not sending as someone.

And when you pin an app to specific scopes, confirm the sign-in scope is still included, or you will fix the data access and break the login.

Verified is not approved

Platform verification is useful information about an application and its developer.

It is not a decision about your data. It does not tell you whether you need the app, whether its scopes are proportionate, or whether the person clicking Allow should be authorizing that exposure. Those decisions stay yours.

The test that matters

After enforcement, test with a normal user account, not an admin.

1. 01 Approved data access

   Open an approved integration that genuinely needs Workspace data.

   Outcome It should work.

2. 02 Sign-in only

   Sign in to something that only needs identity.

   Outcome It should work, and it should get nothing else.

3. 03 Unapproved sensitive access

   Try an unapproved app asking for a sensitive scope.

   Outcome It should stop, and the request should reach you.

Three results, one afternoon. If all three behave, the model is real.

The goal was never zero OAuth applications. It is being able to say, for every application that can reach company data, what it can reach and why. That is the difference between having an OAuth list and having an access model.

Explore this expertise: Identity & Access Management

All technical notes