That's not how OAuth works, which is what "Sign In with Google" utilizes. In order to Sign In with Google through a third-party software, Google and the third-party software must both agree to the arrangement.
In the event they do, the third-party software adds a Google Sign In flow to their software, whereas their users can press a call-to-action for signing in with Google, which would trigger an opening of a separate Google-owned domain in a new min-browser window that the third-party software cannot access (and therefore not harvest information from). This min-window then sends the user back to the third-party software domain upon completion with an authentication token - which could be in the form of a URL query string, an HTTP method, a cookie, or even collection of arbitrary browser information for fingerprinting. The third-party site then sends that authentication token back to Google via their API, and Google sends back ONLY what that authentication token is permitted to grant access to - which would not be Google credentials.
You seem like you might know why the option to pick the authentication company (like Google, but also choose your own that follows the protocol) seems to have disappeared from these boxes, and instead boxes ties to a specific company have multiplied ?
Because those companies incentivize it. For one, you can't use an Oauth integration on your app if you deploy in on the Apple App Store unless you offer Apple as an option, so there's a vector for Apple Oauth hegemony right there. And for Google, it really just makes sense for most users - it's an ethic-neutral option that you know everyone already has and uses daily. Facebook is still a popular Oauth option as well, but has lost a lot of collective conscious trust, so a lot of services don't play ball with supporting them.
It's really as easy as these companies that support Oauth incentivizing third-party devs to use them.
Yes, that's the way it works. But what's stopping a bad actor from putting up a bogus "Sign in with Google" form on their website solely to harvest credentials?
true, but that's only the case if you're currently authenticated with Google. Not true after deleting cookies and/or local storage. But more importantly, less savy tech folks might not be aware that they should not have to re-enter credentials if they have recently logged into gmail or other google owned services.
In the event they do, the third-party software adds a Google Sign In flow to their software, whereas their users can press a call-to-action for signing in with Google, which would trigger an opening of a separate Google-owned domain in a new min-browser window that the third-party software cannot access (and therefore not harvest information from). This min-window then sends the user back to the third-party software domain upon completion with an authentication token - which could be in the form of a URL query string, an HTTP method, a cookie, or even collection of arbitrary browser information for fingerprinting. The third-party site then sends that authentication token back to Google via their API, and Google sends back ONLY what that authentication token is permitted to grant access to - which would not be Google credentials.