Why OAuth Apps Are a Security Risk in SaaS Management

Signing up for a service online used to be really annoying. Even a “short” signup process required you to provide your name, last five addresses, blood type, and employment history. You might think I’m joking, but check out this Cisco forum thread, in which the original poster complained about how he was required to create a nine-digit ID to register for a webinar.

But then in 2006, Blaine Cook began developing a Twitter Open ID implementation. After a few other folks got involved, they realized there were no open standards for API access and suddenly OAuth was born. Before we knew it, we could sign up for just about anything with a single click using our Facebook, Google, Twitter, or LiveJournal credentials. Seriously, LiveJournal. Just ask my former employer.

This tends to make for an incredible user experience. But because of the inherent security risks of using work credentials to create an account, it also can make life for IT miserable. Let’s explore some of the biggest reasons why OAuth is a security risk in SaaS management.

Apps request broad access to your data

Apologies to our entire IT department, but I’ve been guilty in the past of granting an app OAuth access without understanding the breadth of data that I potentially exposed. As our Director of IT Brian Farrell explained to me, OAuth scopes can be really difficult to understand—and many of them request overly broad scopes that grant broad access to modify, delete, and read your data.

I did a little digging to understand how complicated a popular scope can be and stumbled upon some Slack documentation using its API to leverage OAuth in an application build. When you look at the action classes, it doesn’t look too invasive, at least at first glance. 

• Read: Reading the full information about a single resource.
• Write: Modifying the resource in any way e.g. creating, editing, or deleting.
• History: Accessing the message archive of channels, DMs, or private channels.

See? Not too bad. But take a look at the screenshot below of all the actions a developer can leverage to request a large amount of data from a single user’s Slack account.

It took me a minute to understand the list of Associated Methods, but it became clear that many of them grant broad access to chat logs and lists in Slack. Is this a big deal in the hands of an app maker that prioritizes data security? Maybe not. But as we’ve seen over the last 24 months, even the most secure apps are vulnerable to an attack—and a single OAuth token can expose your organization’s data when it ends up in the wrong hands. 

Users don’t think deeply about the access they’re granting

We’ve done a lot of writing about the risk that well-meaning, but under-educated users present to your organization. OAuth tends to be the easiest way for a bad actor to take advantage of lay people like yours truly. And if we’re being honest, even the most careful people on the planet let their guards down occasionally and forget how much access they’re granting when they use a Google Workspace account to sign up for an app.

In an article for SecuRing, Damian Rusinek outlined a vulnerability in a Single Sign-On (SSO) mechanism based on OAuth 2.0. This mechanism allowed users to log in to an application using their Active Directory credentials, but a few of the applications integrated with it also allowed users to log in using their Google credentials. The problem? Some of the integrated apps allowed anyone with Google credentials to create a valid account. 

Rusinek’s biggest concern when he wrote this article was how easily a hacker could use any Google account to gain access to sensitive data. But I also ran the article by Farrell, who added that it’s also concerning because users tend to grant OAuth access with company accounts. 

I’m going to use myself as an example here to illustrate the security risk. Here’s how easily I could expose BetterCloud’s data through OAuth:

• I discover a Pokemon card that I want to buy
• The selling platform allows me to use a Google account to sign up
• I accidentally select my BetterCloud account instead of my personal account

And that’s kind of it. Suddenly, my BetterCloud credentials are in the hands of an app developer who’s using an SSO mechanism that’s riddled with vulnerabilities. While I might gain the luxury of not having to sign up for a service, I’ve also unwittingly exposed my employer’s data to any number of hackers.

Apps gain indefinite access to your organization’s data

When I sat down to write this article, I did a lot of reading about SSO session timeouts. Typically, session lengths can be anywhere from one to 12 hours. I thought that sounded good until I realized that I was conflating “session length” with “account lifespan.” And according to Farrell, an account you create with SSO lasts for an indefinite amount of time—which means that apps gain an indefinite amount of access to your company’s data.

For most apps, this probably isn’t a horrible outcome. I very much enjoy logging into workplace apps like Slack and Marketo with just a click of a button. But it’s no secret that SSO is prevalent across even the most half-baked apps on the planet. It’s also not breaking news that users can sign up for just about anything with SSO without having to consider the security risks involved. 

Indefinite accounts with popular (and secure) workplace apps are less of a concern than the countless number of unsanctioned apps that we can sign up for using SSO. Raise your hand if you’ve ever signed up for a free trial of a service, decided you didn’t like it, and quickly deleted it from your memory. While it might not cost you any money to keep that account open, it also means that your account is still active—and more worrisome, your credentials are still ripe for the picking by a bad actor.

It might seem impossible to keep track of how many random applications users across your organization are using work credentials to sign up for. This is the part where I show you how BetterCloud helps you gain visibility and control over this level of madness.

Using BetterCloud to discover risky OAuth apps

Are you surprised that we’re wrapping up this article by showing you how to mitigate the risk of OAuth with BetterCloud? Neither am I.

BetterCloud’s Discover functionality gives you a deep understanding of all the SaaS applications in use across your organization. This includes apps that IT has approved, as well as any apps that employees have granted OAuth access to unwittingly. 

In the screenshot below, you’ll see the following fields about each OAuth app that’s currently running in your cloud environment, including:

• Application (Name)
• Category
• Status
• New, In Review, Sanctioned, or Unsanctioned
• Discovered By SSO or OAuth
• Discovered Date
• Users
• Integration 
• Permissions

Not only does this give IT the visibility it needs to understand which apps are running in your organization’s cloud environment, but it enables your team to be more proactive when it discovers a risky OAuth application in your stack. 

Speaking of being proactive, we recently discussed how BetterCloud’s Alerts feature gives you an automatic heads up about any changes or issues related to users, files, or groups within your organization. At the risk of sounding like an infomercial, this means IT doesn’t need to constantly stare at the Applications dashboard in case something goes awry.

OAuth apps are a deceptively large risk to your SaaS environment. This is one of several reasons why IT leaders are embracing a zero-touch IT mindset to help them discover questionable applications, take proactive steps to manage them, and ultimately create a more secure cloud environment for their organizations.

Want to learn more about how BetterCloud can help you discover, manage, and secure your entire SaaS environment? Schedule a demo.