Skip to main content
Every time an employee clicks “Sign in with Google” or “Allow” on a third-party app, they grant that app a set of OAuth scopes — permissions to act on their Google Workspace data. Some scopes only reveal an email address; others let an app read every email, send mail as the user, or manage every account in your domain. Synk.to classifies each Google Workspace OAuth scope by how much damage it could do in the wrong hands, and uses that classification to rate every discovered app and grant.

​
How Synk.to discovers OAuth grants

Synk.to reads OAuth activity from the Google Workspace Admin SDK Reports API — the same audit log you see under Reporting → Audit and investigation → OAuth log events in the Google Admin console. For this, Synk.to requests the read-only admin.reports.audit.readonly scope when you connect Google Workspace.
  • History — on first connection, Synk.to looks back 6 months, then keeps discovery up to date continuously.
  • Events — app authorizations and OAuth token requests are recorded as grants; revocations are shown in each app’s OAuth activity.
  • Per grant Synk.to records the app name, OAuth client ID, the user who granted access, the scopes granted, the Google products and APIs the app used, and the IP address.
Events are grouped into discovered systems (one per app) with the full set of scopes, the list of users who granted access, and first/last seen dates. Operating system and browser clients (Chrome, Safari, Firefox, Edge, iOS, Android, macOS, Windows) are excluded, since they are not third-party apps.

​
Scope risk tiers

Each scope is assigned to one of the following tiers:

​
Example scopes by tier

.../auth/ stands for https://www.googleapis.com/auth/. Synk.to classifies close to 60 Google Workspace scopes across Gmail, Drive, Calendar, Contacts, Docs, Sheets, Slides, Forms, Chat, Tasks, Admin SDK, Google Analytics, Tag Manager, and Google Cloud. In the app, each scope is shown as a colored chip with its label — hover over it to see the full scope.
The scope classification is maintained by Synk.to and applies to all customers. If you think a scope is misclassified, or you see an important scope marked as Unknown, let us know at support@synk.to.

​
How an app’s risk is calculated

Risk is driven by the most dangerous permission, not by the number of permissions:
  1. Grant risk — each user’s grant takes the highest tier among its scopes. A grant with openid, email, and gmail.send is Critical, because a single Critical scope is enough to cause a Critical incident. Unknown scopes never raise a grant above its known scopes.
  2. App scope risk — a discovered app takes the highest tier across all of its users’ grants. If one user granted an app full Drive access, the app is rated for full Drive access.
  3. Final risk — the app’s scope risk is combined with the vendor risk of the company behind it, and the higher of the two wins. A Low-scope app built by a Critical-risk vendor is Critical; a Critical-scope app from a Very Low-risk vendor is still Critical.
Hover over any Risk badge on the Systems or Discovered systems page to see the breakdown: Vendor, OAuth scopes, and Final. Use the OAuth risk and Vendor risk filters to narrow the list by either dimension.

​
Alerts and weekly digest

Scope risk also drives Synk.to’s notifications:
  • Alerts — two alert rules are enabled by default with a High or above threshold, which you can change on the Alerts page:
    • New risky system discovered — a new app appears whose scopes meet the threshold.
    • New user provided risky scope — a user grants an existing app scopes they didn’t hold before, and those scopes meet the threshold.
  • Weekly digest — the Risky authorization activity sections list every new authorization in the past week that includes at least one High or Critical scope, split into:
    • apps that have an owner or come from a lower-risk vendor, and
    • apps from unknown or high-risk vendors — the ones to review first.
Synk.to surfaces risky grants but doesn’t revoke them. To remove an app’s access, go to Security → Access and data control → API controls → Manage third-party app access in the Google Admin console, where you can block the app or revoke its tokens.