Social logins provide user convenience and remove the risks associated with weak or reused passwords. That’s not the full story though - giving users the power to grant access permissions to third party apps is a risky trade-off. We explain the technology behind ‘social logins’ and explore ways to identify and manage the associated risks.

A major airline website got hacked. Millions of emails and passwords have been dumped online. You read all about it, and feel that relief that someone else is dealing with the mess, and it's not affecting you or the IT infrastructure you manage. Or is it? It's pretty common for employees to use their work email address to register with sites like airlines or food-delivery apps. It's equally common for people to re-use passwords. A well-known technique to compromise user accounts is to take usernames and passwords from a breached website and try them out elsewhere. A work email address can give a good indication of some sites to target. A great solution to this problem is to encourage users to use social logins, like “Login with Google”. It means users don’t have to create passwords when signing up with web sites and applications. Social logins use a secure technology called OpenID Connect, or OIDC. At no time is the password given to the website, so if the airline site gets hacked, there are no passwords to be exposed and tried elsewhere. A special protocol is used so that the social login provider (in this case, Google) authenticates the user, and then confirms to the web application that the credentials are correct. If you have enforced two-factor authentication for your G Suite users (which you really ought to), then this will be required too, giving additional security. It’s a win-win, in terms of making users’ lives easier, and reducing security risks. For this reason many IT managers take a benign approach to their users using "Login with Google" (technically, OpenID Connect, or OIDC) on other websites or third party SaaS apps.

What is OAuth?

OpenID Connect (OIDC) often sits on top of another layer called OAuth2. OIDC deals with authentication, whereas OAuth2 looks after authorization.

In plain English, that means that OIDC confirms that you are who you say you are, whereas OAuth2 lets you tell a web application what it is allowed to do.

You’ve probably seen OAuth2 in action with those Google screens that say “Application X wants to access your Google Account”. They explain what the application wants to be allowed to do, with some smaller text urging you to think through the risks, and a nice big blue button saying “Allow”.

‍

‍

Herein lies the danger of OIDC: that same technology that lets you sign-up securely, is also an enabler for OAuth2, making it very easy for web applications to request permissions to do all sorts of things to your G Suite data.

Humans are pretty bad at reading the small-print (think of all those terms and conditions you’ve blindly accepted), and pretty good at quickly clicking big blue buttons.

Google has a formal verification program where application vendors have to show how these permissions are used, and the riskiest permissions require an additional layer of security checks.

But giving your users free-reign to use OAuth2 is a big step. You’re relying on Google’s sometimes cursory checks, and your employees correctly assessing security risks.

Are you OK with a marketing company reading all your emails?

A good example of a completely legitimate use of OAuth2 is a site called Rakuten Cash Back. Websites pay Rakuten to promote them to you, and Rakuten shares some of this money with you if you make purchases. One way to confirm purchases is for Rakuten to look through your email inbox and check for order confirmations from their partner websites. To enable this, you get shown an OAuth2 dialog asking you to grant Rakuten access to read all your Gmail if you sign-in with your G Suite account.

That’s right — you are about to give a marketing company the ability to read all your email.

Rakuten is a well-established and substantial company. They adhere to Google’s security program, and are even part of a Google scheme which rewards ethical hackers who can find security holes in Rakuten’s use of OAuth2.

All the same, are you really comfortable with a marketing company having access to private employee emails?

What other web applications have your users been granting permissions to? What about applications requesting access to Google Drive folders of potentially sensitive documents, or admin level permissions to modify your G Suite domain settings?

How can you block OAuth2 in G Suite?

One approach could be to stop everyone using OAuth2. There are thousands of applications that use OAuth2 to do useful and powerful things to make employees more productive, so blocking everything might not help relations with your users and stakeholders.

The other way is long-winded. You have to regularly look at all the applications that have requested access to G Suite, try to find applications you’re unhappy with, then try to find which users are using them. Finally, you can revoke this access but there’s nothing to stop those, or other users re-granting access.

Up until July 2020 these have been your only options: a draconian lockdown, or a time-consuming continual tracking process.

The good news is that Google has since added a new feature for G Suite administrators to let you block specific applications. This means that whilst you have to invest some time in keeping on top of what permissions are being granted, you can at least be confident that you can permanently block an application you’re unhappy with.

The new settings are in Security > API Controls.

The top panel is called App Access Control and the button you are looking for is called Manage Third-Party App Access.

‍

‍

This shows you a list of all the applications that have been granted access to G Suite in one form or another.

‍

‍

You can click on one of the rows to see the specific details of the services that the application has requested and been granted by G Suite. Google calls them Google service APIs — technically they’re known as OAuth Scopes.

‍

‍

The App Access panel at the top has an Access Configuration option which lets you choose Blocked if you want to block access going forwards.

‍

‍

The Third-Party App Access list shows individual “OAuth Client IDs”, and a single application can be assigned multiple Client IDs, so you may need to go back to the main list and find all instances of the application you want to block.

This is great where applications have already requested access, but what if you’re inspired by this article to pre-emptively block Rakuten, or another application you’ve read about?

Go back to the Third-Party App Access Control list, and click Configure new app. Choose OAuth App Name Or Client ID, and then search.

‍

‍

This will show you a list of OAuth Client IDs (there may be several). Select them all, and click the blue Select button at the bottom right.

‍

‍

You can then select Blocked and click the Configure button to confirm.

‍

‍

How can SaaS management tools help manage G Suite?

This is a super helpful feature, but G Suite’s admin console still leaves you with the job of tracking down which applications are requesting these permissions and investigating each one.

That’s where a SaaS management tool like Trelica can help.

With a couple of clicks (including a blue “Approve” OAuth2 button!), you can connect Trelica to your G Suite domain. We automatically discover all apps in use, highlighting potentially risky access by risk-rating each Google service API (OAuth Scope).

‍

‍

These applications are linked to our curated catalog of over 25,000 SaaS applications. We categorize each application to indicate if there’s a legitimate business use, and show information to help you quickly understand the purpose of the application and find out about the vendor. This really helps your decision making process when assessing risk.

‍

‍

Best of all, you can see which users are accessing the application, and Trelica gives you the tools to easily reach out to those users to understand more about their needs, instead of blindly blocking access.

‍

‍

What have your users been accessing?

Start a 14 day trial of Trelica, connect your G Suite admin account and get an instant overview of all OAuth access by your users. Trelica uses a library of over 25,000 apps to immediately identify what your users have been accessing, and flags any risky permission grants such as read / write access to email or Google Drive folders.

Start your trial here – no credit card details required and if you don’t want to continue after 14 days you can simply export all your findings to Excel.

In conclusion

Combining a SaaS management solution, like Trelica, with the new G Suite application blocking feature lets you enjoy the benefits of ‘social login’ without your users building up a risky portfolio of Shadow IT. Left unmanaged, you will need to get used to the idea that your users are deciding which third parties have access to your company’s information.