Comment by tsimionescu
Comment by tsimionescu 4 days ago
This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "hd" field). For individual users they at least provide a "sub" field with a unique user ID (though per the article, it seems this is possibly flaky, or at least misunderstood) - this could be used to make sure that a new user@example.com doesn't get access to the old user@example.com account. But to check if a new user should have access to the organization account, there is nothing that Google provides that can be used securely: all they tell the service provider is that this is a new valid user for the example.com org, not that this is a completely different example.com org.
That's a really good point. Perhaps the protocol should be expanded with an explicit identifier unique to an extant legal entity (or string of identifiers, to account for ownership changes like acquisitions), so it would be easy for SSO-enabled applications to keep previous tenants' data safe from someone who just buys the domain later on.
Of course, this would still rely on the provider: it might be a great solution for large providers like Google which can implement ironclad formal verification procedures, but if you and the previous company self-hosted SSO, you control the response and can impersonate them completely.