Thank you for your interest in Obsidian! Please enter your information in the form and we will contact you shortly to schedule a demo.
The transition of business operations to SaaS comes with a number of significant benefits, from greater ease of use and accessibility to improved cost effectiveness. But perhaps one of the most notable advantages of modern SaaS is the ability for your applications to connect and communicate with one another. Both users and admins integrate services in order to enhance the functionality of a platform, automate specific tasks and workflows, import and export data, or even just play their favorite games. And more often than not, these connections are made with OAuth grants.
From a user perspective, authorizing an application connection with OAuth typically involves little more than a basic dialog prompt and a single click. It’s a simple process that’s easy to complete and forget about entirely. Still, there can be confusion on what exactly is happening behind the scenes with OAuth. And, more importantly, it can be easy to overlook the risks that integrations create in your SaaS environment and how they can be exploited by attackers to gain persistent access to your core SaaS applications and the sensitive data they hold.
To help you better understand OAuth and more effectively protect the applications your business relies on, we’ll break this topic into three primary questions: What is an OAuth Application? What are the risks of OAuth? And last but certainly not least, how do we identify and mitigate OAuth abuse?
OAuth is an open standard for authorization that any application can leverage to provide clients with secure access delegation. Simply put, any device, website, or application authorized with a valid OAuth access token will have permission to access application data without requiring user credentials.
So, what exactly happens when a third-party application connects to one of your core applications via OAuth?
When an end user, often referred to in this context as a “resource owner,” looks to establish this connection, the third-party integration requests authorization from the core application. The user is prompted by the core service to review the permission scopes requested and grant access, typically through a dialog box. Once the user accepts, the third-party application obtains an OAuth access token authorizing them to act within the scope of the granted access.
While individual OAuth access tokens are short-lived, authorized third-party applications are provided with refresh tokens which enable them to continually request new access tokens without repeatedly prompting the user. These longer-lived refresh tokens effectively grant persistent access to your SaaS environment and must be treated securely.
OAuth brings substantial security benefits to cross-application interconnectivity, but sophisticated attackers have adapted their techniques to exploit the framework and establish potentially long-term persistence in your SaaS environment. Identifying malicious patterns and mitigating OAuth abuse starts with an understanding of the fundamental risks of OAuth.
Authorizing an OAuth application can create a variety of potential risks in different forms, whether they are intentionally malicious exploits or simply privacy concerns due to carelessness.
Here’s a clear example of the latter: one of your employees decides to connect their personal Amazon Alexa device to one of your core enterprise applications. Suddenly, the attack surface of your core service has expanded to include the security of that employee’s personal Amazon account. Although this isn’t done with malicious intent, it creates unnecessary OAuth security risk by potentially exposing sensitive business data to an application outside of your company’s scope.
In more intentional cases, attackers may attempt to persuade users to unknowingly authorize malicious OAuth applications with convincingly crafted phishing emails or webpages. If successful, this malicious application will be able to discreetly act and access sensitive data from your SaaS environment, often slipping undetected by security analysts. Not only is this authorization incredibly harmful–it’s also very persistent.
Even vetted OAuth applications in your environment can expose your SaaS environment and sensitive data if they are compromised, as seen most prominently in the recent SUNBURST attacks. In addition, consider the recent Log4J attacks – even if the core SaaS application was not vulnerable, can you confirm if all connected applications have been patched? Likely not. Such cases can be incredibly difficult to identify, potentially allowing attackers to exfiltrate data for long periods of time undetected. This underscores the need to continuously monitor every connection in your SaaS environment for risk, whether the OAuth grant is trusted or not. Simply monitoring the users is insufficient when applying a holistic strategy to SaaS security.
Obsidian continuously monitors every connection to your environment in order to help identify and mitigate OAuth abuse promptly. Our platform provides detailed information on all OAuth grants to your business-critical applications, helping your security team easily ascertain the scope of permissions and activities related to each connection. Our analysis of each OAuth application keeps you informed of connections that are especially risky or outright malicious.
This approach to mitigating OAuth abuse is part of our wider comprehensive approach to SaaS security based on a deep, consolidated understanding of every part of your environment: users, activities, configurations, and permissions. Continuous monitoring and verification of each of these components is what makes Obsidian the first solution to bring true zero trust to your business-critical applications.
Want to learn more about OAuth abuse? Read our blog on securing OAuth for Microsoft environments.