Comment by stackghost

To clarify, any multi-tenant app that has a Google login button that "just works" without you having to set up your own OAuth client creds is using the "public" app option. Effectively the OAuth client side doesn't care whether you use a public Gmail account or enterprise Workspaces account to login.

However, on the Workspace Admin side you can set policies as to whether the org accounts can login to arbitrary public apps by default, or set up an app allowlist, etc. It's definitely a best practice not to let your users login to arbitrary apps, even if it's only for the profile data and not other API scopes.

If you do login to a public app with an org account, how that app decides to group/authorize users from (what it perceived as) the same org/domain could be a sensitive procedure with opportunity for exploit, and it seems like maybe Google should offer a more reliable unique org id claim.

If you are making your own internal app then client is going to be internal only by default. Note this is managed in a GCP project. If you're using Workspace and GCP then you may want to use GCP services with built-in Google auth like Cloud Functions, App Engine, Identity Aware Proxy, etc.

Yea "hd" doesn't work here.

Users can make google accounts with corporate domains but without gsuite hosting attached. The same concern applies to just @gmail.com addys. Google has gotten big on nuking inactive accounts now, what stops similar openings where a person's inactive account gets recreated by an attacker and waltz his way into SSO systems? There's some corporate systems (usually benefits) that allow personal emails attached to the same account as work emails for example.

I imagine the fact the author is writing that Google reopened the bug and is issuing a bounty means there are Google engineers more than aware of the issue rather than trying to argue what Google does and does not intend.

> In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application.

There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to.

> Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts.

This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

> Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

> You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP

So Google offers an OAuth integration option that actually restricts access to your specific workspace. Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

> Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

Saving a click: "hd" means "hosted domain"

hd — The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain

I can see value to that being a human readable string, and can see the value of "example.com" being able to be used to SSO for employees of both Example Inc. 1.0, and Example LLC 2.0.

That said, does seem an "hduuid" could be available for those who care, but mysteriously don't care enough to cancel their other SaaS relationships that use OIDC or SAML SSO.

Ah, right, Slack can have their own public oath client which is used for the code grant.

So what happens is: 1. New Workspace org created with same (old) domain name 2. Same domain name is sent in `hd` property, existing email address sent in the `email` property, new uuid in the `sub` property.

If the app is only matching on email instead of sub, then it will grant access to previous user data. Additionally, even if it makes a new user based on the new sub, it may still grant access to other SP resources associated with the existing domain based on the email address or hd value.

Instead there needs to be something like `hd` but uniquely identifying the Workspace org entity itself, not just the domain.

Whoever has access to the inbox and account for bob@DankStartup.com is bob@DankStartup.com. If Google was being asked if the SSN for bob is 123-45-6789 and they were saying yes, then I would agree that's an issue, but all Google is saying is "this person can authenticate to our services as bob@DankStartup.com" and that is true.

>>>It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.

Does Google have any reliable way of knowing that?

>>>There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

I have a personal google workspace account with a few domains. At some point I might want to spin one off to be its own (maybe I start a company). But I'd still expect pat@mydomain.com to keep working throughout. So that's 1 situation.

Yes, this. I also use a service to capture all emails (catch all) so that I can detect any loose ends that might have been overlooked. Services like ForwardMX or Cloudflare can do this for you at relatively low (or no) cost.

Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?

Probably sue the failed startup owners for negligence?

If DankStartup left all your HR files lying around in their office and the guy who bought it five years later found them, well, DankStartup should have shredded them. It'd sure be nice if the cleaners shredded them for you, but I wouldn't count on it (nor make them liable).

In a rational world the remedy would be to sue Google for exposing your payroll information.

> To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others

But they are providing a unique, stable, never reused identifier tied to the account, as has been mentioned a number of times in this thread. It's the "sub" field[0], whose entire purpose is to be the unique identifier for tying the IDP's data to the RP's data.

What they're not doing is to provide that unique id in the "email" field, because the purpose of the email field is to contain the email address. The documentation even specifically tells not to use it as the primary identifier.

> The e-mail should only be used as metadata for contact info

Indeed. But that's up to the relying party. The only way to prevent them from checking the wrong field would be to not provide them the email address at all, even when they're explicitly requesting it.

[0] https://developers.google.com/identity/openid-connect/openid...

The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse.

https://support.google.com/a/answer/33314?hl=en&co=DASHER._F...

To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it. I believe other IdPs like Okta and Entra have equivalent features too.

SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway.

Any accounts you need after leaving a company should be tied to your personal email.

Can’t you just actively delete the company accounts when closing down?

There should be some service for permanently destroying a domain with a single prepaid cost. Somehow preventing bankruptcy laws from getting the domain.

Pay X$ up front, then Y$ per month to keep active. Once you cannot pay, it gets blocked forever (paid for by the up front cost). Owned by your service provider so not part of your firesale

Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem?

They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported".

If they as administrators cannot do that, Sue has now lost significant business data, there will be a dexent amount of work stopped to get Sue onboarded again and this is a significant issue.

An auditable log that X reset Sue's password ane 2FA codes at x time while at x location with biometric authentication is pretty secure. If X also ca nnot touch those logs the next strawman falls apart.

  By looking the account up with Google's People API - https://developers.google.com/people
  They would have to verify the account is active

  AND the id hasn't changed

  If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users.

It is certainly an option to pre-provision accounts in your application (e.g. Slack) and then have any users authenticating from the SSO product compared against the list of authorized users. And for some products which sell licenses by seat, this is exactly what they do.

But for many products which are meant to be available to an entire organization, this is a big part of what SSO was supposed to solve in the first place: IT no longer has to provision (and de-provision) user accounts in every single application. Maintaining an allowlist in each application makes this pointless.

Maybe you can clarify what part of the linked comment didn't make sense? It's a bit hard to make out where the confusion is if the above comment didn't help clarify.

Where does this “directory of active users” exist? If it is controlled by slack, then you are relying on a failed startup to properly notify ALL the 3rd parties when they shut down. Failed startups don’t always shut down cleanly like that.

That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.

Where would this directory be stored?

I'm not entirely clear on what you expect in this case?

You're registering with those 3rd parties using a property (the email address under corpdomain.com) that is now owned by the new party.

This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved.

You've sold the domain. Assets associated with the domain are under the control of a new party. For all Google knows, you did this entirely above board and in a coordinated fashion.

That new party controls the property. Email resets will also dump right into their hands (They control the MX records for corpdomain.com now...).

Legally speaking, it's not even clear you're right - the new person might well be the person actually entitled and expressly supposed to be accessing that service as that account (if the domain was sold as part of an acquisition or sale).

Seems like relying on domain alone is a design flaw of OAuth?

So you use email/pass and the reset password email dumps right to the new party as well, because they control the MX records for the domain?

Yes, but that's not a bug with Google OAuth. If Taskrabbit (in the example) decides to trust dankstartup.com emails as a root of trust for identity even though the business failed, that's on them[1], and certainly nothing Google can have prevented.

The contention in the article is that dankstartup.com's new owners can leverage their control of the domain to get access to existing OAuth-based sessions that will look to the service providers as if Google has authenticated the account holder.

[1] And just to repeat: that risk is precisely why serious businesses (Vanguard in the example) don't allow obscure email domains as authentication anymore.

It's better than SMS based password recovery or "call support to reset your password". What do you suggest is the best approach.

I don't think it would need to go that far. Simply tying it to a Google Workspace account and not to the domain should be plenty good enough. Google knows if example.com changes between being associated with Google Workspace A to Google Workspace B. But it's not including that info in the OAuth claims.

Agreed. I've also seen "The Fine Article"