Is it safe to allow my employees to connect third-party apps to our M365/Google Workspace tenant?

It’s no secret that SaaS use is growing exponentially, but less has been said about third-party SaaS integrations, especially to core platforms like M365 or Google Workspace. In this article, we’ll explain what these third-party integrations are and what the security benefits vs risks of using them in your organization are. We’ll also provide some helpful tips about what you can do to remediate or at least lessen the risks.

What are third-party SaaS integrations and what the heck is OAuth?

A third-party SaaS integration with your M365 or Google Workspace deployment allows an employee (or administrator) to grant some level of access to your data by that SaaS vendor. Employees want to connect these apps because they want to easily share projects across their tools, or integrate add-on features that make their workspaces more flexible or customized to their needs, or they simply need them to be more productive. And those apps must have some level of access to your data (and the employee’s data) to function properly. The problem comes in primarily because the level of access each app requests can vary significantly by both the type of data exposed and the number of employees it affects. 

It can be as simple as sharing an employee’s full name and email address with the SaaS provider if they login using their business Microsoft/Google account, otherwise known as a "social login." However, integrations can also request access to much more sensitive data, such as email inboxes and document stores (OneDrive, Sharepoint, Google Drive). Employees with administrative privileges can even create integrations that allow access to all employees’ data, rather than sharing only their own data. 

Clearly, the security and compliance risks associated are highly variable depending on the type of integration.

OAuth is an industry standard protocol for authorization (https://oauth.net/2/). If you want to share your data on one app with another third-party app, rather than share your username and password, OAuth provides a way to authorize access to specific data based on a set of permissions. You can even later revoke access to specific apps without changing your password. A vendor that allows sharing of their data via OAuth can implement their own custom permissions - Google implements hundreds of permissions alone (https://developers.google.com/identity/protocols/oauth2/scopes). 

Essentially, OAuth is the protocol that allows you to easily choose which data you share with who and thus is a very common approach for how SaaS platforms integrate with other core SaaS platforms like Google or Microsoft.    

An Example - Adobe Creative Cloud

Let’s say your Marketing team wants to make use of Adobe Creative Cloud - perhaps they need Photoshop for some image-editing and Acrobat for some PDF-editing for marketing materials. They pop along to https://creativecloud.adobe.com/ and click to sign up and are presented with the following choice: 

Your organization is using Google Workspace for most core business functions, so they think “Oh great, I can login using my business Google account, no need to setup yet another online account and password!”

They click to “Continue with Google” and are presented with the choice to select their account. They are already logged in with Google so they don’t even need to enter their password.

That’s it, they are now signed up to Adobe Creative Cloud, they pay their subscription and start using Adobe’s SaaS offerings. This is known as a Social Login, and it lets your marketing team quickly and easily log into Adobe using their existing Google account.

However, very limited data access has actually been provided to Adobe. Adobe has only been authorized to access basic details of the employee who signed up, as you can see in the integration details below:

However, after some use of Photoshop and Acrobat, your marketing team needs to both open and save documents on their Google Drive or OneDrive as that’s how they collaborate on all other documents within the company. No problem, Adobe allows you to add one of many cloud storage options. Given your company is using Google Drive, they pick that option and are presented with a new permission request from Google:

This time, Adobe is requesting much more sensitive access than merely basic personal details - it’s asking for full read/write access to the employee’s entire Google Drive store. Google makes sure that’s clear and asks for authorization. Your employee clicks to continue and now they have the ability to read and write Google Drive from within Acrobat:

We can now see a new integration has been created, exposing a much more significant asset by allowing full access to Google Drive on behalf of the marketing employee.

We have just followed a user journey for two particularly common examples of integrations, but there are a huge number of SaaS providers out there and a huge variety of different types of integrations. However, the most common cases are simple social logins, document access, email access, calendar access and contacts access depending on the SaaS provider in use.

Should I be worried about this?

As always, the answer is “it depends.” On the one hand, by default your employees can enable integrations for their own account with whatever third parties they like and potentially expose very sensitive data assets like document stores and email. It’s a bit melodramatic to put it this way, but consenting to OAuth permissions is like giving a third party an everlasting password to act in a limited capacity as a number of users with minimal monitoring and trusting them not to abuse that access.  

On the other, many integrations (especially the ones you’ll recognize by name) don’t ask for excessive permissions, and are managed by responsible and security conscious vendors that generally do a great job of securing your data. The challenge is finding integrations for which this isn’t true.

The reality is that it’s probably already happening across your organization, whether you know it or not. After all, SaaS use is key to modern working environments and your employees will be using it somehow. At Push Security, it’s not unusual for us to see hundreds of third-party integrations on our customers’ Google Workspace and M365 instances, even in relatively small organizations. 

And in fact it’s not all doom and gloom, since your employees need to use SaaS providers anyway, there are actually some security benefits to making use of social logins and third party SaaS integrations are the key mechanism for doing so. 

This is a key reason to not take a heavy-handed stance of “block all integrations” - while you would certainly reduce the risk of data leaks, you’d also be losing the security benefits of social logins and severely hindering your employees from getting things done quickly and easily. You will also probably force them into effectively doing the same in a different way anyway (perhaps they simply start using their personal google account and google drive where they can do these integrations instead?).

What are the security benefits?

There are a number of security benefits to using social logins and third-party integrations, but a few key considerations are:

• Fewer passwords - if your employees use social logins everywhere, they can focus on having one strong password and not have to manage separate accounts and passwords for 20 different SaaS platforms.

• MFA everywhere - if you have set up strong password policies and enforced MFA on your Google and Microsoft accounts, all of your SaaS platforms inherit the same security if you are using social logins.

• Visibility of SaaS use - if employees use custom logins for all their SaaS platforms, you’ll have no idea what SaaS is in use (unless you use the Push browser extension ;)). With social logins and third-party integrations, you can see exactly what integrations you have across your organization, including which employees have shared which type of data access.

• Fine-grained permissions - OAuth integrations can request as little or as much access as they like. Ideally, many integrations will be nothing more than a social login or will otherwise limit the permissions to a small subset of data they require to reduce the risk. This is far more transparent than alternatives like integrations using API keys typically are.

What are the security risks?

• Blindspots in your attack surface - At a higher level, you need to care because each of these third parties is now handling your data and you need to ensure they only have access to what they need to function, that they’re storing and managing your data responsibly, and that you treat them as you would any other vendor in your supply chain.

• Excessive permissions - Third-party integrations can request whatever permissions they like. Some SaaS apps may choose to request excessively high permissions and simply not function unless an employee accepts it. This can lead to employees being conditioned to accept permissions whatever they are and granting excessive permissions.

• Consent phishing - A technique that tricks a user into granting a malicious third-party app access to their account. Since this technique preys on users that are already logged in, it is effective against users with strong passwords, multi-factor authentication, or even passwordless setups. You can read more about this technique in our previous blog post. SANS had a breach in 2020 caused by a consent phishing attack, which led to a leak of around 28,000 records of SANs members’ personal information (PII).

• SaaS account compromise - If an employee has a separate account and password for a SaaS platform and that is compromised somehow, any integrations with your Google workspace or M365 are also compromised. For example, perhaps they have a weak password with no MFA on a SaaS provider and then an attacker uses that to access Google Drive via a pre-existing integration from that SaaS platform.

• SaaS provider compromise - If a SaaS provider itself is compromised, any integrations could also be exploited. This is the SaaS integration equivalent of an MSP or other third party with privileged access to your data being compromised. Hubspot experienced a breach in April 2022, which “allowed malicious actors the ability to access and export contact data using the employee's access to several HubSpot accounts.”

• Stolen integration tokens - The way integrations work under the hood are via OAuth tokens. If these are stolen somehow, due to a device compromise or SaaS provider compromise, they can potentially be used to gain access to data, similar to if a password was stolen in the same circumstances. They also do not expire on a password change, so changing a password after a compromise is not enough on its own to deal with this threat. A recent example of this was the exploitation of GitHub via tokens stolen from Heroku and TravisCI.

• Integration backdoors - Integrations provide another method of backdoor access to a user account post-compromise. Setting up a malicious integration is one method to maintain access to data that will survive a password change conducted as part of incident response. A real-world example of this issue was a privilege escalation attack in Azure, covered nicely here.

Security guidance tips for third-party integrations

Let’s face it, your employees need to use SaaS solutions to be productive and they are going to use them somehow. We have even seen how third-party SaaS integrations can provide some security benefits, too, but there are new risks to be aware of as well. Here are some basic security tips to consider to ensure you are enabling this practice securely.

• Gain visibility - Whether you know it or not, your employees are probably using SaaS platforms, which may include third-party SaaS integrations. Find out what SaaS platforms and integrations are in use and pay attention to any with sensitive permissions you might want to review. Push can help do this for you.

• Remove dormant or infrequently used integrations - Reduce your attack surface by simply removing the apps no one or only a few people are using. This also makes the third-party security vetting process a bit less burdensome, so it’s a smart move once you know which integrations won’t be missed when they’re gone. We can help with this as well.

• Modify incident response playbooks - If you have incident response playbooks in place for what to do in the event of an employee’s password being compromised or their laptop/mobile being stolen or infected with malware, you need to consider modifying these. Consider adding invalidating SaaS OAuth tokens in addition to standard steps like password changes, remote wipes and fresh device builds.

• Encourage social logins - Social logins have a bit of a bad rap, possibly this is due to their roots in low security, non-work environments - but that being said, when using your M365 or Workspace as the identity source these methods are a great for for many organizations that struggle with weak passwords, shared passwords and a lack of MFA across SaaS apps. If you're going to be using social logins, it makes sense to ensure your Google/Microsoft accounts have good password policies and MFA. 

• Educate your users about consent phishing - Awareness of traditional phishing for passwords is pretty high these days, but awareness about consent phishing is far lower. Make sure your employees are aware of this as well and know who to speak to if they’re worried they consented to a malicious app.

• Admin approval for sensitive permissions - M365 has an admin approval process for integrations and allows you to define low risk permissions that users can consent to themselves. This can allow you to empower users to use social logins and lower risk integrations on their own, but require an admin to approve apps requiring more sensitive permissions. Google workspace allows you to configure restricted permissions but is much less flexible. Check out Microsoft’s admin consent workflow guide and their article about how to configure permissions for more guidance.

• Prioritize apps that need additional vetting - prioritize apps based on how many people in the company use it and if it’s requesting access to highly sensitive data to work or integrating with SaaS that have data you don’t want exposed. We provided some more practical guidance on risk prioritization here.