← Back to context

Comment by placardloop

4 days ago

> Suppose DankStartup folds … Isn't that a failure on DankStartup's part, to not shut down their business accounts?

Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately.

* - not every startup that folds has “failed”, but the point still stands

11 comments

placardloop

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

  • danudey  4 days ago

    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.

    • horsawlarway  4 days ago

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

      3 replies →

  • placardloop  4 days ago

    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.