The way I understand it, the whole concept of OAuth/SSO involves allowing a user the ability to have a central password they can use on a multitude of sites without compromising it because really they're signing into the service hosting their password.

Now, barring the use of two-factor authentication, as the average user does not use this feature, and using Google's SSO feature as an example, but realizing this applies to every similar service:

What stops me from writing an app that simply informs a user that we support sign in with Google and instead of redirecting them to the appropriate SSO page, I just provide a place for their Google username and password. I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal, and also store their Google username and password on my private server for malicious purpose later?

And if the answer is nothing would stop me, then why isn't 2 factor authentication mandatory on all these implementations?

  • 1
    what's preventing you? The threat of prison time. The ability for people to detect your phishing URL. 2FA doesn't really help here either except U2F Jan 18, 2017 at 1:46
  • It doesn't have to be a phishing url, that's my point. It can be a legitimate site that "incorectly" implements OAuth/SSO. Jan 18, 2017 at 18:27
  • This is just a phishing attack, not inherently possible because of OAuth. You can lure the user to login to a false web site with all authentication methods - doesn't matter if it's pure user/pass login, OpenID, OAuth... doesn't matter. No online user/pass login mechanism protects you from the phishing attack you just described.
    – luben
    Mar 5, 2017 at 13:02

1 Answer 1


Aside from the legal aspects alluded to by Neil McGuigan in the comments, it's also difficult to perfectly emulate, say, Google. For one thing, when I log in, Google shows my profile picture. Second, it asks me to perform my 2FA validation (I know, you're assuming most people don't use this, but for those who do, its absence is a red flag).

Reading your question closely, I just noticed this statement:

I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal

What exactly do you mean by this? Assuming at this point you've captured the users credentials, how do you then turn around and use them to actually perform SSO? There's no way for your server to authenticate with those credentials in a way that sets the correct cookies in the user's browser, which is important for SSO to work.

Really, if you were going to execute this kind of attack, it would be better to fake the SSO as well, or omit it entirely, and just store the credentials for later retrieval.

But, none of this is specific to OAuth or SSO itself. It's just a phishing attempt, no matter how its initiated.

  • By emulate the user, I mean I use their username and password my app stole to do the app authorization as far as google is concerned. That way, they can see that my app is "registered". Jan 18, 2017 at 18:23
  • 1
    Maybe I should've ask a different question then. "Does OAuth / SSO make phishing attempts easier?" Jan 18, 2017 at 18:25
  • 1
    No, it doesn't. It makes it harder, since you need to do more work.
    – Mike Caron
    Jan 18, 2017 at 19:59

You must log in to answer this question.

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