A bad Facebook admin who can spoof your Facebook login can post bad stuff under your name on Facebook, and that is usually considered worse than posting a question on Stack Exchange.
My more detailed answer is focused on OAuth 2.0 which is the industry standard for this use case and is behind the Google's authorization sketch in the OP1.
The OAuth 2.0 framework is not originally meant only for authentication, but for the more general use case of authorization: Service A wants to access some resource owned by the User on Service B.
For example, the User has both an account on Service A (a photo editing app) and on Service B (Google Drive). With OAuth 2.0, the User grants to the app the authorization to access their photos on Goole Drive. Some attention points:
- Service A needs to be a registered app on Service B: in the example, the developer had to register her photo editing app on Google Developer. When initiating the authorization flow, service A identifies itself to Service B via client id and client secret (if server side flow) or client id and hostname (if client side flow).
- Service A redirects the User to Service B's authorization endpoint, and the User needs to input their Service B's credential only on Service B. Service A can't spoof the login for Service B, because it doesn't control the authorization endpoint. Service B can't spoof the login for Service A, because it is not provided by the User.
- The final Token Response, which Service A can use to access the User's resource on Service B, comes with a scope. Service B will let Service A access only resources which are within the authorized scope. The scope is explained to the User in the authorization window they are redirected to. In the example, the authorization window from Google Drive will explain something like "This photo editing app can see and modify your photos on Drive". Google will then allow the app to access the photos, but not to post something on Google Plus, because it is not within the authorized scope.
Third party login is a very common special case, where the resource owned by the User is their basic account info on Service B. Instead of requiring the User to register on her service, the developer chose to ask Google to verify the identity of the User.
The system only works if
- Service A trusts Service B
- The User trusts Service B
The nice thing is that the User does not have to trust Service A.
If the User, however, trusts Service A more than Service B, they should not use the third party login and register on Service A (when the option is available).
1 Original Post