Comment by stackghost 4 days ago
>Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately.
Sure, I'm sympathetic to that, but again I don't see how that's within the scope of oauth.
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).
> 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).
No, this is absolutely not the case. If you were selling the identity, you would transfer access to the Google Workspace account. There is no reason whatsoever that a new Google Workspace account should have access to the same services as a completely different Google Workspace account just because they happen to use the same DNS domain.
> I'm not entirely clear on what you expect in this case?
Not parent-poster, but from what I can piece together it sounds like the distinction between Google attesting that:
1. This is the person who currently controls the same e-mail address.
2. The is the person who currently controls a sub-account of the same Google Workspace which was in the past identified by this e-mail address.
> You've sold the domain. Assets associated with the domain are under the control of a new party.
True, but that "control" does not (and should not) automatically mean legal ownership of every kind of internet account that was ever made with that e-mail address.
While the prior-controller has a degree of responsibility, so does Google when it knows that ownership of those other facets were not transferred.
> 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.
I feel the analogy need at least three kinds of party: The old/new home owners, the lawn-cutting service, and a marketplace or middleman which is failing to pass along the change in ownership.
The other reply to this comment kind of nailed it, but in short:
Right now Google, via OAuth, attests that someone's identity is "user@domain" as a unique global key, even if they know that that user@domain is controlled by a new Google workspace (i.e. it is not the same people/organization/legal entity).
All Google has to do is attest that someone's identity is ("user@domain", "unique workspace ID") as a unique global key and all of this will go away.
> 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.
I think it's more like hiring a lawn service through a third party, and then, after you move, a second person moves into your house and calls the lawn service asking for a copy of all of the credit card receipts from your payments and they give it to the person because the third party assures them it's the same person, even though it's not, just because the address is the same.
> Email resets will also dump right into their hands (They control the MX records for corpdomain.com now...).
Well yes, and people shouldn't use e-mail/password authentication for that and many other reasons (unless 2FA is involved).
The difference is that, in this case, we are outsourcing authentication to Google under the assumption that Google will handle authentication better than just a username/password combination; I'm relying on Google to say "yes, this is who that person claims to be and we have verified that". The problem is that Google knows that they is not who they claim to be, that they just have the same e-mail address but a different workspace, but they're still telling the other site that yep, it's him for sure, absolutely, and the other site has no way of validating that any of that is true so they have to go with it.
> 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).
Potentially yes, but if that were the case then they would have transferred ownership/control of the workspace itself, including all of the accounts, email, google drive data, and so on, and not deleted the entire workspace and created a new one from scratch. In a case where they did want to do that (e.g. to migrate off of Google workspaces or consolidate) that seems like something they should do via customer support to ensure continuity.
OAuth allows you to provide information above and beyond just the domain, and the article describes examples of how this could be done. This is just a flaw in how Google presents an identity to OAuth clients.
In other words, right now it's basically "user@domain", but it could be ("user@domain", "unique workspace ID") which would prevent these sorts of attacks as well as make logical sense.
If a security mechanism doesn’t account for failure cases, it’s a failure of the security mechanism.
It’s a hard problem to solve and I don’t have a solution, but it’s a core goal of every security tool to account for edge cases and failure cases like this. If you tell me that OAuth is completely insecure due to a security issue, it’s not going to make me feel any better if you say “but it’s totally not OAuths fault” - I don’t care who’s fault or scope it is, the end result of a security issue is the same, and to avoid it I’m just not going to use 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?
I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses.
Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new payment info, new users, etc.
Google knows that these are two different workspaces and that there is effectively no connection between the two other than the domain, but they are not presenting that information through OAuth (which is possible) so other companies are not able to do any sort of diligence in ensuring that the correct people are accessing that data.
OAuth provides the capability to make this distinction, but Google is (or was?) refusing to provide data to other companies to allow them to make that distinction.
This sounds hyperbolic, but Google is effectively lying to these other services that that someone else is in fact the original person that service expects, even though Google knows full well (or is capable of knowing) that that is almost definitely not the case.