In the above example, the Company doesn't have anything to do with the Google account that the user created themselves.

I don't know if Google is the best example here. Apple might be a better one:

1. User's work email is [email protected]

2. User creates Apple ID using their work email. Their Apple ID is [email protected]

3. User gets fired and their company email is deleted

4. User can still sign in to the SaaS apps using SIWA and their "company" Apple ID

It's worth noting that OAuth providers - like Apple - include information such as if they are authoratitive or not over a particular account.

In the above example, the normal flow to get a Google address [email protected] relies on setting DNS records for company.com, both to prove control of the domain as well as to route email to that domain. There may be an exploit/bypass I'm not seeing, but I legitimately don't see any way a user who has a legitimate [email protected] email address hosted somewhere besides Google workspace could then setup a [email protected] email address with Google.

If there's a way to do this, I would greatly appreciate a link or brief explanation, as our process for employee termination/resignation does involve disabling in the Google admin portal and if we need to be more proactive I definitely want to know.

The issue here is that if company.com does not use Google Workspace and hasn't claimed company.com, then any employee can sign up for a "consumer" Google account using [email protected].

There are legitimate reasons for this, e.g. imagine an employee at a company that uses Office365 needing to set up an account for Google Adwords.

You can sign up for google with an existing email. So if example.com is all on MS365 that's where the admins control stuff. No google workspace at all, no DNS records or proof of domain to anyone but MS.

So anyone with an example.com email can make a google account using that email as their login. Verify they have the email and that's their login. A common system for users who need to use google ads or analytics.

But when the company disables 365 login the google account remains. And if you use something third party that offers a "Sign in with google" then assumes because you have a google account ending "example.com" you are verified as "example.com" you've got access even if that account is disabled.

If you have the google admin portal this doesn't work as you're controlling it there. But signing up for Microsoft or Apple accounts with that google workspace address might have the same loophole.

The example states that the user works at Example Co and email is @example.com

This is the confusion — it’s reasonable to assume that the email is not a personal address.

That removes you from their system. If I make a GitHub account using [email protected], GitHub doesn't get notified that I got fired from example.com, so I can keep using my GitHub [email protected] account in places that ask GitHub if I'm [email protected] even though I don't have access to that email anymore.

This no longer happens for services that have accounts that follow a social media style. For such accounts, employees are expected their own accounts (presumably with followers, reputation etc.) and keep it after leaving the company. For real social media, this is probably fine, but I don't understand why we accept this model for Github and Gitlab (and Sourceware before that). Even from an employee perspective, it's not great because it makes it unclear who owns what. Especially with services like Github which have rules about how many accounts you can create for one person, and under what circumstances.

I have no idea how this is supposed to work in practice for Github and Gitlab, where people gain access to non-public areas of those websites, but they are still expected to use their own accounts which they keep after leaving their employer.

(The enterprise-managed Github accounts do not address this because they prevent public, upstream collaboration.)