Comment by patmcc 4 days ago
>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y".
Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?
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.
But the new owner does not have access to the inbox or any other account info of the old bob@DankStartup.com. They're completely separate accounts, with the same email address. Plus, Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns (though per the article, it seems that may not work properly).
And legal relations just don't work this way. A person is who they are, and it is that person who has legal access to whatever data was stored in their Slack. Another person who happens to have the same email some time later doesn't have any right whatsoever to that same data. OAuth exists to help secure this type of legal relation, not to establish a completely fictitious identity.
> Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns
Then Google is doing the right thing. It's incumbent on the relying party to enforce its own authorization policies based on the information the authorization server provides.
Google says, "here's bob@example.net <id=n49d0x>", oh now "here's bob@example.net <id=pv82x1d>"
Google can't save consumers from their own negligence.
>>>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.
> Does Google have any reliable way of knowing that?
Yes, Google knows this is a new Google Workspace account using the same domain as the old one.
> 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.
That should be a separate feature of Google Workspace, where you can transfer an identity, it shouldn't be automatic. And it shouldn't even be tied to the domain name. If you decided that you prefer the domain to be pat@mybetterdomain.com, you'd still want to have access to the old Slack conversations or whatever. Conversely, if you lost access to the mydomain.com domain (say you forgot to renew it, or some legal entity sued for it because it was their trademark or whatever), I'm certain you wouldn't want the new owners to then have access to your Slack or any other data, just because they have the same domain name.
>>>Yes, Google knows this is a new Google Workspace account using the same domain as the old one.
I agree it knows that, but it doesn't know:
>>>It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.
How should it verify that? Should it? If you buy a domain that was used ten years ago, do you want google to say "well, we can't let you use contact@newDomain.com, someone used it previously and it may be confusing".
>>>I'm certain you wouldn't want the new owners to then have access to your Slack or any other data, just because they have the same domain name.
Maybe nobody should be using domain name and/or email address as authentication, but that ship has sailed in 100 different ways.
Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
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.
Presumably after 10 years of failing to collect on their invoices, Microsoft would have killed your O365 account, so there's one fewer SaaS account left to log into.
Common sense would dictat that you have sunset your business by this time.
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).
> Probably sue the failed startup owners for negligence
The owners generally aren't liable (assuming or corp or LLC), and if the company would have been liable, that liability probably died with the firm.
In a rational world the remedy would be to sue Google for exposing your payroll information.
Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?
Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.
> 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...
It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.
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.