Who Do You Trust? OAuth Client Application Trends

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 numbers of users using a particular scope is risky due to the wide usage, but often this is because an application has become a corporate or de facto standard by a well-known company, so the risk factor is more related to the application. Whereas, less-known applications used by few users tend to reflect individual choices and decisions to use applications that are not approved,which reflects more on risky user behavior.

Through this framework, we can start to identify the biggest risk areas to focus on for reducing risk, as we’ll attempt in the following sections.

Overly permissive scopes

Overly permissive scopes include unneeded manage/modify/write permissions or just extra permissions that an application may not require, for example:

• A scope such as “View and manage the files in your Google Drive” raises the question of whether write access is required or would “View the files in your Google Drive” or “View and manage Google Drive files and folders that you have opened or created with this app” suffice?
• Extra permissions or scopes being requested that are unexpected for that application could also raise questions (e.g. a spreadsheet application requesting access to contacts).

To gain a sense of higher impact applications, here are the top 20 applications in terms of users that request the “View and manage your mail” scope:

As expected, most of the apps relate to email, but with less obvious applications, it’s worth reviewing, for example:

• Adobe Acrobat is a well-known PDF read/write application, but why does it need read and write access to email? It turns out there is feature that could readily explain this scope request: Gmail integration to send PDFs by email. However, this shows how a convenience feature (being able to easily email PDFs), increases exposure because the application, Acrobat, has full access to your email. This could be acceptable but should be an explicit decision.

As a different example, in our dataset, there is one application trusted by one user, appears only in one organization. It appears to be an internal tool, its title relates to GSuite Security alerts and its list of scopes are:

Manage data access permissions for users on your domain
Manage delegated admin roles for your domain
Manage messages in groups on your domain
Manage the l