There are multiple mechanisms (some now defunct) that allow me to access service A (the Relying Party / RP) using a token granted by service B (the Identity Provider / IdP). Typically these replace a username-and-password login. Examples of IdP protocols include:

  • OpenID 2.0
  • OpenID Connect
  • IndieAuth
  • Mozilla Persona
  • Portier
  • ...and obviously Google Sign-In and Facebook Login

What stops the IdP from gaining access to my account on the RP? Surely a bad actor with sysadmin privileges at the IdP can:

  1. Make a login attempt at service A
  2. ...initiating a token request from A to B
  3. Generate a token at service B (without needing my credentials)
  4. ...return the valid response to A
  5. Now access my account at A

I'm asking a general question, but as a concrete example, what stops a bad Facebook admin from posting Stack Exchange questions under my name?

Rough sketch:

Bad admin generates the authorization code

(Sketch adapted from https://developers.google.com/identity/protocols/OAuth2 but note that the referenced protocol is just an example.)

  • 2
    This would depend if you just use the third party login, or 2FA also
    – jrtapsell
    Commented May 28, 2018 at 12:25
  • I don't think you should be worried about Facebook or Google themselves posting stuff in your name. Having a weak Facebook password and being able to use that to access other sites, that I find a bit more worrying.
    – ChatterOne
    Commented May 29, 2018 at 7:14
  • Normally in this situation you don't have an account on service A, that's why you use a token from service B in the first place Commented May 29, 2018 at 10:47
  • @MarioTrucco are you saying that, semantically, you post to service A from your service B account, rather than you log into service A with your service B token? the spoofing issue still stands (service B can spoof you at any service that accepts tokens from service B)
    – lofidevops
    Commented May 29, 2018 at 12:44
  • 8
    ....this feels like a specific example of a general problem: "what stops my identity provider doing something on my behalf?" (for good or ill). The fact that it's OAuth2 is somewhat moot. The answer is "nothing" - it's like you're trusting the government not to issue a duplicate driver's license to impersonate you (after all, they control the printing mechanism). Commented May 29, 2018 at 17:35

4 Answers 4


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.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – schroeder
    Commented Jun 14, 2018 at 14:48

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

  1. Service A trusts Service B
  2. 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

  • +1! Key point: except in a resource owner flow (which would not happen for this use case) Service A never captures your credentials. They can only perform the actions permitted by the scopes in the token. Commented May 30, 2018 at 12:28

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.


Yes. Which is why there's technology available that makes this impossible (such as privacy-preserving attribute-based credentials) but it's considered to be too impractical for average users as of now (and I'm not aware of any software with reasonably usability and there's zero browser support for it). This technology doesn't allow them to impersonate you and even more so logins can be done without connection to a central provider. (The problem with current approaches is that you leak what sites you're using to the identity provider).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .