We’re now all too familiar with the ubiquitous “Sign in with Google” button we encounter all over the internet. For most of us, it has become the go-to “easy button” for managing the sprawling set of accounts we’ve created. Behind that button is an OAuth grant—a tokenized mechanism for providing any given third-party tool access to information stored in our Google account. Many of these grants provide access to only basic information such as a user’s name and email. But an increasing number of tools also require delegated access to additional services, such as sending email, or accessing Google Drive files. Great, right?

‍

Sure, this is great in many ways, and makes our digital lives much easier—but it’s also a huge security headache to manage at scale, within an organizational setting. First, how do you know the third-party service should be trusted? Not an easy question to answer. How do you know your employees are making good choices when clicking through those screens? Not easy at all! Our modern web of OAuth grants is an unmanaged risk most organizations are just beginning to understand. Not only do most organizations lack visibility into what technology is actually in use, but worse, they rarely have insight into the data being shared across these apps through the privileged OAuth grants created.

‍

The challenges with OAuth grants are many, but they all center around the granularity of controls provided by those technologies that issue them. To use Google or Microsoft as our prime examples, we are limited by the ability to establish scalable policies. Simply placing an app on an allow list or block list is a limited solution. For instance: Salesforce may be an appropriate solution to integrate into Google, but should I allow it to see only my employees’ contact information? Their calendars? Their inbox? This is a classic example where the initial security review and controls put in place may assume a certain scope of data, but an OAuth grant quickly changes that exposure.

‍

The controls for OAuth grants available to us operate at the app level, which doesn’t allow  us to set policies for the scopes contained within the grant. If one were to block an app entirely, an employee would encounter an error message—and then likely pursue another path to create an account or establish an app-to-app integration. 

‍

In an ideal world, we would manage these grants with generic policies, not app-specific decisions. We should be driving toward the ability to establish policies such as, “Allow OAuth grants for apps that have been certified by google, that do not require scopes beyond sign in,” or, “Disallow OAuth grants that provide access to files, source code, or admin functions.” Unfortunately, this is far beyond where we are today, but the necessary step for managing OAuth grants at scale.

‍

As we look forward to the new era of interoperability between the apps that we use, we can certainly expect new levels of productivity—but we also need to recognize the new reality of risk. We need tools that allow them to analyze OAuth grants based on the scopes they contain and the data they access, and to work with both the employee to justify those connections as well as the security organization to accept the corresponding risk.

‍

How Nudge Security can help

Managing OAuth begins with visibility. Nudge Security continuously discovers your organization’s SaaS assets and OAuth grants, maps your SaaS supply chain, and monitors for publicly exposed SaaS applications and domains. What’s more, we compile this inventory into a searchable dashboard to help you readily visualize and manage the full extent of your SaaS attack surface. 

‍

Nudge Security’s OAuth risk management features allow you to view and monitor all OAuth grants, and event filter by grant type (sign in or integration) and sort by application, age, number of scopes, the user who granted access, or by our proprietary OAuth risk score. You can even drill down into any one of these individual grants to see a more detailed view of individual scopes, risks, and OAuth history in order to prioritize response.