Understanding OAuth(2) security: what's a realistic threat model?

I don't believe this addresses the question at all, because the question is asking about threat to the user. I personally suspect that adopting 3rd party authentication is often not driven by threat to the user, but threat to the operator. I am posting this since the OP said he'd prefer it as an answer, so 🤷

I claim that this benefit is not specific to OAuth, but applied to using any 3rd party auth service, for which OAuth is one model. So, it's not about OAuth per se, but just outsourcing the auth to some other entity. From the operators point of view, the threat model of DIY auth is:

• If accounts get hacked and users complain, they have to deal with them (which takes time and energy) instead of sending them straight to the third party
  • Note - sometimes, the "hack" is entirely the user's fault, due to using guessable passwords or sharing it too much, but they blame the site anyway and it takes time to deal with it
• If accounts get hacked and there's a media scandal, it becomes "your fault" and you can lose reputation and brand value rather than just blaming the third party
  • Note - when handling PR scandals, it's important that your "defense" is not just credible but also short, sweet and quick. Otherwise, even if the scandal is not your fault, your response won't reach many people and they will continue blaming you. Saying "it was X third party's fault, they do our logins" can be deployed very rapidly.
  • It is also much more convincing to say "we were paying XYZ to do our Auth and they dropped the ball, we have now fired them and switched to ABC, trust us again" than to say "our programmers fixed the issue, won't happen again, trust us again".
• If accounts get hacked and there's a lawsuit, there's no one to shift the liability to, except at best your employees
• When users, and more importantly investors, business partners and regulators, question the professionalism of your security strategy, you may have to undergo lengthy audits and endless meetings trying to satisfy someone who doesn't know what they want. Whereas it is much easier to say "we use industry standard XYZ service" which everybody has already learned to trust, while convincing them that your DIY solution is just as good requires a lot more time and effort
  • This is because the third party auth provider, given that it's their core business, has invested a lot of money and effort into PR/marketing to make everyone believe that they're secure, whether it's true or not, whereas to you, the "security marketing" budget is just something that competes with the "my product/service is best" marketing budget.
• Whenever you introduce something which improves security but harms the convenience or privacy they will blame you. But with a third party users are less critical. There is a sort of diffusion of responsibility because your org can't help the bad UX/privacy because now they delegated that to the third party, and the third party can't change things for this one case because they need to have a service secure enough for everybody.
• When the 3rd party messes up, there does not appear to be a culture of blaming their customers for choosing their service. Our society seems to find it acceptable that your org simply took the auth provider's marketing (where they have the nice padlock clip art and the "secure" green checkmarks) at face value without trying to look past the marketing. The org is not blamed much for choosing to use a service that turns out to do a bad job.
  • This is reminiscent of "nobody gets fired for buying IBM".
• You need to hire engineers knowledgeable about security, and such people command much higher compensations currently.
• You need to screen candidates for knowledge about security, but this might be difficult because your managers are themselves clueless about it.

In short, the decision to use third party auth is not a transaction where the reward is improving user security. Rather, it is a transaction where the reward is reducing financial and legal risk to the organization. The security and experience of the user may even be degraded, but this can be viewed as just part of the cost.

You might gather from my tone that I disagree with much of this on the grounds of ethics and I have few qualms about co-opting my answer into a platform to whine about it :). But it's hard to deny that there are many business advantages for a website operator that comes from outsourcing a tricky bit of work (account security) to someone else.

You will also have to pardon me for not providing any hard evidence to back this up. Business decisions and strategy tends not to be accessible to the public where it can be easily cited. I am appealing to the reader's capacity for reasoning logically and to ask "cui bono".

posted 5 months ago

CC BY-SA 4.0

5mo ago

matthewsnyder‭

1050 reputation 32 35 142 34

Threats

In my head, there are three main threats, though the OAuth 2 RFC has a whole chapter on the topic. Your questions deal mostly with one of them and slightly with another.

Fake login page

You asked some great questions on this. There are several ways^[1][2] (not comprehensive) that people are tricked into providing bar.com credentials, but with care you can avoid them.

Granting more access than expected

OAuth 2 has "scopes" for authorizing specific access to or actions on bar.com. A malicious foo.com may ask for more data on you than it strictly needs. This is similar to the old days of Android permissions: "Why does a flashlight app need to read my emails?"

Identity sharing

Both sites now know that you're a member of the other. This is not necessarily more dangerous than signing up with an email, and in some cases exactly equivalent: If bar.com is an email provider^[3] and you were already going to sign up on foo.com with that email, using OAuth probably isn't any worse. (Assuming foo.com sends you at least one email that is recognizable as originating from it.)

• If you don't want Microsoft to know that you have an account on embarrassingphotos.example.com, don't "Sign in with GitHub" to it.
• Also vice versa: Don't link accounts if you're worried foo.com will find all your public friends on bar.com and threaten to tell them your nefarious foo.com activity.

Questions

I skipped one of your questions that I think is a duplicate of another one. If you can articulate the difference, I can try to address it.

• If I am not already logged in at bar.com, I should always log in separately before attempting to authenticate, correct? There is no way that foo.com can provide me with a login window and prove to me that it's secure (i.e., that they aren't MITMing me)?

The login window is from bar.com. The foo.com site typically sends the current page or a new tab to bar.com to do the sign-in.^[2:1] You do need to make sure that it's not sending you to a lookalike URL,^[1:1] but the certificate should all be fine since it's completely the other site.

• Similarly, if I believe I'm logged in at bar.com already, but trying the foo.com authentication link gives me a login form, I should reject this and treat it as a phishing attempt, correct?

That would certainly be fishy, but it's the same situation as above. You should be able to tell that you're on the right site by examining the certificate chain and verifying that it's not using lookalike characters^[1:2] in the domain.

• When I give bar.com permission to authenticate me to foo.com, how do I know that this won't compromise my bar.com login? What information is actually communicated per the OAuth protocol?

At no point are your credentials passed anywhere (except if you signed into bar.com to see the interstitial, and only bar.com gets those).

OAuth2 bolts some authorization on top of the authentication, which lets them also say "and here is the list of things my user says you can ask from their account and/or do to their account." In those cases, foo.com has to ask for the permissions, and bar.com shows them to you to grant or deny. Some sites may allow you to choose which things to grant. Some may just let you accept/reject the whole slate. If foo.com asks for things you didn't expect, maybe it's not a service you should trust.

The flow looks like this: foo.com opens a request in your browser to bar.com so your existing session is valid. It asks for the scopes it wants. If you approve the scopes in the interstitial, bar.com sends you back to foo.com with a short-lived code. Then, foo.com's backend issues a request with that code directly to bar.com so a user's browser, extensions, and network can't interfere with it. If bar.com agrees, it gives foo.com a longer-lived token.

• When I give such permission, typically bar.com will warn me that foo.com wants permission to access (or know) certain information about my bar.com account. How can I be sure that only that information is being transmitted?

You don't, really. You can make your own requesting site, though, and see that it really does only give you the things that you agreed to on bar.com.

Like any software, it can do all sorts of things, and they can be unsafe. And since it's a website, the software can change at any time. All of this is incumbent on bar.com not doing the wrong thing, though. None of it depends on foo.com (though you hope foo.com doesn't leak data either).

• Could foo.com ever gain the ability to modify my bar.com account information?

Yes. See above. Many sites issue permissions called "scopes" (that it asks you about, on first registration), to do things like load your profile picture or integrate with your calendar on bar.com. Or it can wait and ask (with a new interstitial) for permission to do that later, after your first registration.

• Could it happen that the authentication appears to just work without me giving consent on a bar.com interstitial? If that happened, what should I do?

I wouldn't expect that the first time, but as above: software can do anything, so bar.com could do that. After the first registration, yes, I'd expect it to bounce between foo -> bar -> foo when you load up a foo.com page, and do all that seamlessly without your input.

If it happened the first time you registered (or if you revoked foo.com access), I'd complain to the owners of bar.com. That would be a security hole in their site.

posted 8 months ago

CC BY-SA 4.0

5mo ago

Michael‭

204 reputation 6 8 25 33