Comment by kbolino
4 months ago
If you're using Google for identity and authentication, you can definitely control who has an active account in your domain. There can be some lag time before disabling or removing someone truly disables all their downstream accesses, but that's largely outside Google's control. The only way to trick your way into getting a corporate domain email address is to socially engineer a domain admin.
Tangentially, this does raise one of my big issues with using OAuth2 for single-sign-on though, which is that it really doesn't address the third-party authorization problem well. Ok, you're bob@example.com, Google has verified that, and example.com is our domain, so we're letting you into our app Foobar. Now what? The scopes you requested were for Google APIs only and have nothing to do with Foobar really. So now we need to implement an authorization system in Foobar that decides what bob@example.com can actually do. This part, and how to do it right, gets glossed over (at best!) by discussions on OAuth2. It also gets glossed over by product and security when they want things "SSO-enabled", which means development time doesn't get budgeted for it. Even just using groups to control coarse access levels requires integration with provider-specific APIs. OAuth2 is great for identity and authentication, but far too little attention has been paid to doing authorization right.
This comment makes the most sense to me in this thread.
Further, IMO, sure it's a bug that one can say they control support@company.com. But IMO the real issue is lousy, permissive authorisation that gives access to anything simply by virtue of controlling a @company.com mail. Surely some HR/tech person, when an employee is being onboarded, should be enabling access to some core systems (probably by adding them to a group), and the default state for an account with no groups should be no access.
In any large enough organisation, IME there's a lot of ways to get a @org.com email, and too many people/systems have the ability to create an email than a single centralised IT team.
You can also create a non-email Google account as Bob+external@example.com, as long as you can get email sent to bob@example.com (ie, while you are employed by Example, Inc). Then, you leave your job, but still have a google account associated with an example.com email. Depending on how the app checks the login response, they might mistakenly assume you are part of the example.com org.
I'm pretty sure you cannot create a personal account for "bob+external@example.com", as Google both knows about plus-suffixes (didn't they create them?) and any domains already managed under Workspaces. They also, in my experience, seem to have some understanding of domains managed by Microsoft's cloud and perhaps other competitors as well.
But even so, there's another mechanism, which is that when you create an OAuth2-enabled project in Google's console, you can specify that only known users in your domain are allowed to authenticate through it. This would lock out any personal account anyway.