Zurück 
Introduction
Federated identity systems, such as Google Identity, bring security and convenience in the form of SSO for Internet or cloud applications. It is common to be prompted for authentication in order to grant various levels of access or permissions for applications ranging from Google Drive, Google Cloud SDK, Google Chrome plugins, Slack, Adobe, Dropbox, or Atlassian to numerous third-party apps.
This is all part of OAuth client application authentication, where a user can securely enter their credentials (which are not shared with the requesting application) and approve the privileges or access (scopes) requested by the application.
However, this set of trust relationships can cause security problems, such as data exposure/loss or data modification, if malicious applications or overly broad permissions are granted.
In this blog, we take a closer look at real-world user activity showing which applications are being trusted and which scopes (permissions) are being granted using Google Identity given its widespread adoption. We’ll analyze anonymized data from Netskope customers that includes 439 organizations, over 500,000 users, and over 60,000 applications. We will look specifically at:
- Modify/write permissions most requested by applications
- Which apps may pose more risk to users
- Overly broad scopes that increase risk
It’s a wonderful application world
What kind of applications are being trusted by corporate Google identities, and therefore, likely being accessed from work computers/devices?
Here are the top-12 applications that are trusted by at least 5% of the users:
These 12 applications alone are trusted by 497,109 of the users (97% of the total users). Some of these might be official or de facto corporate standards such as Google Chrome (log into Chrome with your Google Identity), Zoom, Slack, Atlassian, or Adobe. Other applications such as iOS Account Manager or Android device or macOS, represent trust to native applications running on those operating systems (e.g. Mail, Chrome, Google Drive).
We also see specialized applications and personal applications:
Scope creep
What kind of permissions (OAuth scopes) are being approved by all these applications?
Here are the top 10 scopes (ranked by # of users) that grant “manage” (modify) permissions:
In this list, the “view and manage spreadsheets in Google Drive” scope is requested by the most applications: 11,124 (18.3% of all apps). Some questions that come to mind:
- Do all of the apps requesting these scopes require “manage” as well as “view” permissions?
- Does the “View and manage the files in your Google Drive” scope really require access to all files or could/should it be restricted to “View and manage Google Drive files and folders that you have opened or created with this app?”
From a security viewpoint, it would be ideal if application access was restricted to only the data they generate themselves. For these types of cloud apps, their scopes would have a narrow set of privileges such as:
- View and manage Google Drive files and folders that you have opened or created with this app
- View and manage forms that this application has been installed in
- View and manage your data for this application
However, there are valid example types that require broader privileges such as general file sharing or search applications that might need access to your whole Google Drive, or a photo-editing application that needs access to all image/video file types regardless of origin.
It would be natural to focus on applications that request potentially broad scopes and that have higher risk due to the high number of users using those applications. This helps us identify risky applications. Many of these applications have high user counts because they are popular or are corporate standards.
However, we shouldn’t ignore applications with broad scopes that are only used by a few users. These applications may not be popular and may not be developed by well known vendors. However, if they have risk, it indicates that you may have users engaging in risky behavior. This helps us identify risky users.
In general, we can look at scope-based risk along two dimensions and locate applications within the matrix:
The scope dimension reflects the breadth of permissions allowed by the scope ranging from narrow to broad. The # of users dimension identifies the number of users that use a particular scope. High n