I wonder why Google would make an SSO assertion along the lines of "yes, this user Bob has email address [email protected]" in the situation where example.com is not under a Workspace account. Such assertions ought to be made only for Workspace (and Google's own domains such as gmail.com, googlemail.com, etc.) since outside of that it's obsolete proof as you say, i.e. it's merely a username of a Google account which happens to look like an email address, and nothing more.

You can create a google account with an existing email

https://support.google.com/accounts/answer/176347?hl=en&co=G...

I read the GP's question as "why" would Google allow that in the first place?

The reason is obvious: because a Google account gets you access to many a Google service without requiring you to open a Gmail account.

However, the question still stands: why does Google allow authentication with a non-Gmail/Workspace account? Yes, it would be confusing since not all Google Accounts would be made the same, but this entire class of security issues would disappear.

So it's the usual UX convenience vs security.

Alternative "fix" that's both convenient and secure is to have every company use Google Apps on their domain ;-)

Every time I've left an organization, they have swiftly deleted the company email address/revoked my access to it. I assume every reasonable organization will have processes in place to do this.

I don't see this as a vulnerability: how is Google supposed to know that a person has left the company? You let them know by deleting the account.

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.)

You don't need full blown workspace, which costs money, you can set up "cloud identity free" and claim the domain.

When you're setting it up, you can choose what to do with any existing accounts that are part of your domain: kick them out or merge them in.

This is the right answer for this problem. If you're not interested in being a paying workspace customer, get cloud identity free and verify your domain. You can then take over and/or kick out any consumer users in the domain.

I want to add that I actively use this feature of unmanaged users. I have my own Google Workspace on my own domain. Years ago when I bought a Nest product I found that I couldn't use a Google Workspace account to access Nest. No problem, I create a consumer Google account under my Google Workspace domain. The email looks just like a Workspace account. And it doesn't need any additional Workspace licenses. (I no longer plan to buy any more Nest devices so I'll delete the account once my last Nest product stops working.)

Perhaps the following could be a solution to this issue?

Any OAuth provider should send a flag called "attest_identity_ownership" (false, true) as part of the uaht flow, which is set to true if the account is a workspace account or gmail (or the equivalent for other services), and false if the email is an outside email. Thus, the service handling the login could decide whether to trust the login or proceed otherwise, e.g. by telling the user to use a different OAuth service/internal mechanism where the identity is attested.

This is why you store and match on the sso provider’s uuid, not on the email address. Emails are not a unique identifier and never have been. Someone can delete their email account and later someone else can sign up and claim the same email. Anyone matching on email addresses is doing it wrong. I’ve tried to argue this to management at companies I’ve worked at in the past, but most see my concern as paranoid.