Comment by johnmaguire 4 days ago
This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912
"hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.
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.
If I'm understanding your comment correctly there are three different ways to connect Google SSO to your application:
1. SAML. This avoids the issue because certificates need to be exchanged between Google and your application, but an attacker that recreates a duplicate workspace using your domain won't have access to those certificates. Only users from your workspace will be allowed to login.
2. A custom Google OIDC IdP configured for internal access only. This also avoids the issue because a secret key is required to set this up and the attacker won't have access to that key. Again, only users from your workspace will be allowed to login.
3. The public Google OAuth API which will allow any Google user from any workspace (or non-workspace users) to login to your application.
Is this correct?
Assuming the above is correct, if you decide to connect Google SSO to your application using option (3), then it is not a vulnerability that a Google account from a different workspace can connect to your application, because the entire point of option (3) is that users with any Google account (regardless of workspace) can connect to your application.
If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).
I don't think so, but please go ahead and clarify if that is the case.