Public cloud adoption rates have been rising for some time, and the global pandemic has accelerated the trend. In fact, nearly 60% of enterprises expect cloud technology usage to exceed prior plans due to COVID-19. In the age of heightened public cloud adoption and widespread cloud Software-as-a-Service (SaaS) usage, cybercriminals are making use of OAuth – a permissions delegation and authorization protocol – to compromise cloud environments. As such, controlling which applications users interact with has become a business imperative.

Let’s take a closer look at what OAuth is, the role it plays in allowing users to access resources across environments, the ways attackers are abusing OAuth and what organizations can do to better protect their cloud data.

Understanding OAuth

Authenticating and authorizing user access for dissimilar systems has been a challenge since the beginning of computerized systems. One answer to this problem has been the birth of single sign-on (SSO) platforms, which allow end users to log in once to access a variety of applications and resources without reauthenticating. Modern applications and the explosion of public cloud services and cloud-hosted data have made it critical to enable users to share information from their cloud accounts with third-party applications.

Released as an open standard in 2010, OAuth provides SSO capabilities to end users who require access to resources across many environments. OAuth is an authorization protocol, which means it provides permission for users to access certain resources (as opposed to validating their identity). Google and other cloud service providers have strongly supported OAuth since its inception, and its evolution (OAuth 2.0) features new security capabilities used by most cloud service providers today.

How is OAuth Used Today?

Each time a third-party application requests APIs that are system-centric to user mobile devices, the mobile device will display a prompt for approval of the permissions request (such as using the GPS data via the underlying system API). While APIs can function as security gatekeepers that grant permissions to exchange information, there are problems with this type of permissions approval. API permissions are easily revoked in most sites such as Google, Facebook, and those that have been granted can be easily forgotten.

How does this relate to OAuth permissions delegation? As an example, Google uses OAuth 2.0 credentials to delegate permissions to API resources. All applications follow the same basic pattern to access a Google API using OAuth 2.0.

First, application owners obtain OAuth 2.0 credentials from the Google API Console. Next, before a third-party application can access private user data using the Google API, it must obtain an access token that grants access to the Google API. Then the scope of access granted by the user and returned in the access token are compared to the scopes required to access application features and functionality. The application should disable features and capabilities unable to function without access to the related API. Once the Google Authorization Server provides the token, it is sent to the Google API as an HTTP authorization request header. The access tokens granted by the Google Authorization Server have a limited lifetime, but applications can request a refresh token when needed.

Most users are accustomed to simply "clicking allow" on permissions requests by third-party applications. As such, attackers may easily persuade end-users to grant the high-level permissions requested by malicious applications.

How Attackers Abuse OAuth

Although the OAuth standard itself includes security measures, attackers can abuse it for malicious purposes. Some examples of OAuth abuse today include:

●Leveraging OAuth to help malicious applications retrieve account data. Attackers can craftily impersonate legitimate third-party applications to access account data. For instance, an attacker could create a legitimate looking malicious app, request OAuth tokens to access account data and then use this OAuth token to leak data from a user's account. These types of scenarios underscore how critical it is to reconsider your stance on allowing third-party application installations in cloud SaaS environments like Google Workspace or Microsoft 365.

• Capitalizing on OAuth implementation weaknesses. Some applications leveraging OAuth do not require application secrets and are susceptible to access token leakage and abuse. Attackers can use a variety of methods to harvest OAuth tokens, including eavesdropping, cross-site scripting, or social engineering techniques. Once an attacker has access to a compromised OAuth token, they can access the end user's personal information. Additionally, they can use the OAuth token to conduct other malicious activities such as spreading malware on behalf of the compromised user or launch a cloud ransomware attack.

Protecting Your Cloud Data

OAuth provides a modern way for applications to access private data contained in your applications or cloud service provider environments. That said, the rise in cloud adoption and subsequent interest in compromising cloud environments means you must also bolster security for your business-critical systems and data in other ways. With the rapid shift to distributed, remote work, this has never been truer than it is today.

We live in the day and age where applications now span on-premises, cloud, and hybrid environments. Attackers can use a wide breadth of tactics to compromise cloud environments and cloud SaaS platforms. In particular, they’re looking for ways to abuse OAuth authorization for cloud services and often use social engineering and malicious applications that pose as harmless apps to compromise your data, steal information, or even introduce ransomware.

Consider leveraging AI-based application control approaches to monitor and enforce which third-party applications or browser extensions can integrate into your SaaS environment to get full visibility of the scope of permissions granted to access your Google Workspace or Microsoft 365 data using OAuth 2.0. Doing so will allow you to maintain behavior databases and reputation analyses for thousands of applications, and identify which are safe. In order to prevent OAuth abuse by malicious applications, you must take a proactive approach to managing which applications your users access, and which can and should integrate with your cloud SaaS environment.