The wrong way to block "Sign in with Google"

If you’re a startup, chances are you’re using Google Workspace, and also using Google as your identity provider. This is convenient, since your team can use single sign-on to “sign in with Google” to most SaaS apps you use: they get access without needing to manage a username and password, and the login is tied to their account, so that when they leave, they lose access.

Well, kind of. Google is an identity provider, and it’s a good authenticator, but a bad governor. It'll tell an app who someone is when they log in, and that they’re part of your org. It won't tell you what they can do once they're in, and it won't reliably take it away: you can't guarantee that when someone leaves their access is gone, since you likely can't enforce that Google is used for SSO in every SaaS app. None of which means you should buy something else on day zero. Google is still the right IdP when you’re starting out. (Google is also often special-cased in SaaS app pricing, like it’s not a ‘real’ authenticator worth charging more for 🤷‍♀️.) You should just be aware of what it is and isn’t doing for you.

Google works well for ensuring users can access the apps that they need to. But one of the reasons you want an IdP is to help you manage what folks have access to in your organization, including limiting which apps are used — so why don't you block users from logging into arbitrary apps with their Google ID? (If you're just learning that was possible now… I think we know why.)

You can block your users from signing into third-party apps with their Google Workspace account by changing the setting for “Unconfigured third-party apps”. "Unconfigured" means anything you haven't already marked Trusted, Limited, or Specific Google data in the app access control list. (If you haven’t spent much time inside Google Admin, most likely all of your apps are unconfigured.) There are three configuration options for handling unconfigured apps:

• Allow users to access any third-party apps. This is the default, and allows your users to access anything, and grant any app any access.
• Allow only apps that ask for basic sign-in info. Users can sign into any apps that just want a name, email address, and profile pic. Any app asking for more is blocked. But this isn’t a filter: if an app wants Drive access, the user doesn't get a degraded version of that app, they just don't get the app at all.
• Block users from accessing any third-party apps you haven’t explicitly configured. This blocks all OAuth scopes, including sign-in.

Configure settings for “Unconfigured third-party apps” in the Google Admin console

Why bother to restrict any apps at all? The main reason is that most users can't distinguish (or don't care) about the difference between logging in and granting an app access to everything in their mailbox. No one reads the consent screen.

The second reason is duller: you should, in theory, know what apps your users are using. Not so you can block anyone, but because you need that list for vendor security reviews and on- and offboarding. The OAuth grants in Google Admin are a starting point for that list, not the list. It tells you what was granted, not what's being used, and it lags changes by a couple of days.

If you block users from new apps, they hit this “Access blocked” screen. Technically, it's a request screen: they can hit “Request Access”, and you can add a custom message telling them what to do. But what happens next is a black box to the user. They submit a request, and they have no idea who it goes to, how long it’ll take to approve, or how long it’ll take to propagate. It might be easier and faster to just hit the back button and sign up with a username and password, or a personal email. It might be easier to just give up on getting access at all. Users tend to pick the path of least resistance.

After the OAuth consent screen to log in with their Google account, users hit this screen where they can request access to an app

So what should you do, if anything? As always, it depends on your risk tolerance, but I'd suggest you pick between the first two options. Allowing only apps that ask for basic sign-in info isn't blocking those grants, it’s blocking those apps, which only makes sense if you have someone reviewing those blocked apps. If you’re not, just leave the free-for-all default.

Either way, you'll end up with apps in your environment you'd rather not have — but if you still let users sign in to them, at least you'll have a list of them, you'll know who authorized them, and you'll know they're behind SSO. And that's better than not knowing about those apps at all.