Can an identity provider impersonate me? (Can Facebook post Stack Overflow questions under my name?)
Yes, they can.
Simple answer: You authenticate in some way to your identity provider, usually via username and password. The bad admin can store the transmitted credentials and just re-use them. This attack does not depend on how the backend is implemented.
In general your password for the identity provider isn't used for authentication to third-party services at all, which means that your identity provider actually has your login keys (and you do not have them at all).
You could think of schemes which incorporate your password into the authentication process without storing it unencrypted afterwards, but in practice I do not know any such scheme.
TL;DR: 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
Yes they can. Mario has explained how it technically works. I will focus here on the trust part.
Whatever action you do on a computer implies trust. You trust the OS editor of your system and of your phone. You trust all the editors of any programs that you installed on them. You trust any online service that you use. And you trust your bank not to do anything on your account (this one goes beyond informatics...).
But there are some degrees on the trust level. I trust the flight reservation system enough to buy them something, but I do not trust them to the point of giving my banking credentials. Anyway, I trust my password vault program enough for it.
So in a trust chain, what matters is: does one of the actors of the chain only deserve a lower trust level than the overall action? It is probably fine to use a Facebook account for SO, the risk of attack and possible consequences are IMHO compatible with the trust I have in Facebook. But I would never use a Facebook account for my bank (they does not offer it anyway). And of course trusting a system implies trust for any of its admins.