OAuth authentication is not safe. This is the baseline from which all applications should be working. There is a place for social login, but it should be a very restricted domain. It has some significant security flaws, puts your users privacy at risk, and hands away control of your application. Think carefully if you should be providing social login for your web site or application.
This is not a discussion of any technical weaknesses of OAuth, which may exist. I’m focusing on the implications of outsourcing authentication. I don’t dislike social login, and I do use it on my new game site. I’m a bit shocked however when I hear social login used for sensitive systems. I’m writing this to counter such inappropriate use. Perhaps as an indicator of appropriateness, Twitter does not use Twitter Login for their development site.
Open Access
One account gives access to all the applications ever authorized with it. This convenience is one of the appeals of the system, but is also a significant security risk. Somebody who gains access to the account transitively gains access to all of the authorized services. This is particularly troublesome for the types of accounts used for OAuth: social services. These are the accounts most likely to remain logged in at a computer, and used from the most number of devices.
There are ways to limit this type of exposure, such as multi-factor authentication or simply rerequesting the password on each login. I haven’t seen such a feature with Facebook or Twitter. Your application can have its own password, limiting OAuth to the role of identification only. In this case it is important to also offer a logout feature and ensure the user knows about it.
Facebook’s “Login Best Practices” recommend against a double login yet do encourage a logout. It’s unclear if they mean log the user out of Facebook as well, if that is even possible. Clearly if a simple login is just 1-click away, merely logging out of your app is not helpful.
The split between identification and authorization, and multi-factor authentication are important topics in security. Unfortunately the major OAuth providers, like Twitter and Facebook, really don’t put much effort into securing their user’s accounts. Their methods appear focused on blocking spam and fake users. For a social site this is perhaps okay, but for an identification or authentication service this is quite weak.
Loss of control
An application using OAuth loses control of their userbase. The true identity of users, and their ability to login, is controlled by the OAuth provider. Your application can be effectively turned off at any time, for any reason. It may not even be a malicious behaviour; I’m sure everybody has had occasional login troubles at Twitter and Facebook. At those times the user is locked out of all their other applications.
For you, as an application developer, the situation can get even worse. The user is most likely to blame your application for the failure rather than blame the OAuth provider. It’s not unheard of that the Facebook is working yet login via Facebook is failing. In these cases it really does look like your application is to blame. It isn’t technically your problem but you’ll have no ability to help that user. Recall you may not even know how to identify the user. Even if you did, the OAuth providers tend not to offer many debugging options or logs.
It is reasonable to consider that a hosting provider, or even a DNS registrar, also has the ability to disable an application at any time. Those types of services have a few differences. First they tend to be paid service and you are their customer. This is a completely different dynamic than with Twitter or Facebook where you and your application as just incidental to their product. Secondly, infrastructure services are more prone to provide an open service, with possibly even laws to safeguard that behaviour. With OAuth providers you likely had to agree to an arbitrary terms of service with numerous special clauses about content and appropriateness.
Loss of users
Not having the identity of your users is a critical point. I’m saying this again because it is very important. If you have no way to identify, authorize, or communicate with your users except via a third-party then you have a significant business risk. Even a temporary problem by the provider can have a direct impact on your revenue.
Social users can almost be seen as borrowed: they aren’t really your users, they belong to the social site. This is a great way to attract new users, but an easy way to lose them as well. The more data the user has, and the more often they use your app, the more relevant it is to own that user. Be sure to request an email address as part of the OAuth request, or encourage repeat users to provide another ID. In any case, at least providing multiple login providers mitigates the business risk.
Company Access
Even a careful user has no way to control the behaviour of the authentication provider. A user must assume that employees of those providers are able to access their accounts, and in turn access all the applications ever authorized. The user will never be aware of such access.
To pretend this can’t, or hasn’t happened, would be misguided. Without full access to the employee handbook, data security rules, and IT policies we have no idea how safe our accounts are. I’m not certain any of these companies even fall under any sort of law that would regulate their behaviour in this area. I’ve also never seen an audit history accessible to the user.
This may seem like paranoia, but other industries, like banking and medicine, do have strict legal requirements in this area. The safety of your user’s data should not be given to a third-party without duly considering the consequences. Always keep in mind that you are not actually a client of Google or Facebook. Their login is fully under their control and they don’t have any contractual obligations to your application.
Privacy
A central entity that has a wide view of user behaviour is not good for privacy. I already mentioned the unauthorized access issue, but there is plenty of non-malicious activity that leaks information. The primary business activity of the major providers is advertising. Each application a user has authorized provides information about that user. It retains, at a minimum, historical logins, and of course all sharing activity. Even if your application doesn’t use sharing the provider still has a record of “Likes” and comments for the application.
Any level of profile sharing necessarily leaks information. On Facebook I can run an ad campaign for a page. I select the basic demographics; arleady I know quite a bit about the people visiting my page. A lot of banner programs give information about where the ads were clicked, revealing more about the user. Some of these companies, like Twitter, also sells streams of information. Query logs are also often provided, and I’ve had first hand experience on how revealing those are.
This issue of privacy isn’t solely caused by the use of OAuth. A lot of the data leakage happens through ad networks even without OAuth. By using an OAuth provider in the business of marketing though, you are willingly leaking information about your user. For social games this is likely okay, but for any financial or shopping application I don’t think it is acceptable.
Consider Carefully
The OAuth providers an application allows should reflect the type of service they are offering. If a user would be okay with sharing their activities and profile on Facebook, then Facebook is perhaps an acceptable option. If your application contains sensitive information, anything which a user would not be comfortable with sharing, then offering a social login is ultimately a disservice to your users.
Obviously the same consideration must be given to any outsourced service. Databases tend to be the most discussed, but authorization must be considered a vital service. It doesn’t matter how well protected your database is when authorization is weak.
In this article I’ve shown the numerous weaknesses with OAuth/social login. It doesn’t mean there isn’t a place for it. The decision however must be made carefully, and must respect what your users will expect of your application.
Categories: Philosophy, Programming
Musing Mortoray 
I agree with your points, thanks for the good post.
I think the strength of OAuth/Social Login is that there are many users who just won’t bother to sign up for a service at all if they have to go through the process of setting up yet another separate username and password. If you are running some kind of social service, tying yourself into the Google or Facebook or Twitter OAuth infrastructure leaves you at the mercy of those companies in many respects, but it probably increases the chance that users in those spheres will give it a try by an order of magnitude.
Yes, definitely the acquisition of users is easier with social login. For most startups this argument usually trumps all issues of security (no point in securing users of a business that fails). But they certainly should pay attention to the ownership issue (who’s users are they) when building a sustainable business.
A very thoughtful post. A two factor is probably the most secure means of user identification, regardless of OAuth or a security tended to by a development team. The simple fact is that unless you have very stringent controls around password generation, it is hard to prevent a user from using the same password over and over again. A user may even create “Irea11yL0veF@ceb00k!” as a strong password, yet unscrupulously use this everywhere and and expose themselves and the systems they use.
Two factor with a mobile component can alleviate some issues, but even Apple has announced that there is a critical security patch that fixes a grievous SSL error that exposes users to a man in the middle attack. This is quite staggering – the very foundational platforms that we use are full of holes.
Again, great insight with your post.
Very interesting! Is OpenID in any way more secure then OAuth? Does it reveal less information about users to the identity provider?
I believe the key difference with OpenID and OAuth is that OpenID focuses on identification only. That admittedly can be used as a form of authorization, though it probably shouldn’t.
If used as full authorization then it likely suffers from the same issues listed here. If authorization is still an additional step (like extra password) then you at least counter the unauthorized access.
You however don’t prevent the ID company from locking you out of an app. Perhaps the dynamics change however. The OpenID provider doesn’t know about apps, only about ID. So it can block an individual, but not an application.
I’m unsure about the privacy and what information is leaked while using the OpenID protocol.
Well, I disagree with a general statement that OAuth bad.
1. Security. People tend to reuse their passwords when siging up for different services. The more third-party sites know your passwords, the more likely that one of them will eventually be hacked and leak your passwords. Limiting the “circle of trust” helps lowering that risk.
Analogously, do you prefer sharing your credit card information with a random site to complete a purchase, or would you rather go through PayPal?
2. Security (#2). Any site, not only your bank or a brokerage account, could benefit from out of band authentication. However, vast majority of sites don’t go beoynd the basic login/passord, mainly because the costs of implementing and keeping up such security measures are significant. However, if your OAuth provider supports such perks (and they do!), you automatically benefit from their efforts of keeping your credentials protected.
3. Privacy. Nothing prevents you from creating a “proxy” account at a “gmail”, entering bogus personal data and then using that account for all your non-essential logins.
4. Speed and conveninece. If you wanted to check out a website which asked for a login, would you rather fill out a lengthy form or just hand them your authentic or a “proxy account” OAuth token?
While OAuth isn’t bullet-proof, it has brought us all tremendous value. The Internet is constantly offering ever more attractive services to try out. OAuth is a vehicle to move around quickly and with decent balance of privacy and security.
1. Yes, people do reuse passwords. However, a big security issue is that Facebook/Twitter provide a listing of the services used by an account, such that a breach gains simple and easy access to all of these services. Additionally, these social accounts tend to remain logged in, even on public computers. The choice of OAuth provider here is the problem.
2. Out of band is obviously good, but hurts the convenience of 4.
3. Actually the big providers are trying to limit this ability. The requirement for a mobile number to sign up, or gain access to some services, is making it difficult to create alternate personalities. It is even forbidden by the terms of service of some providers.
4. Personally I’m okay with email and password. Too many sites make this hard by requiring confirmation. This step should be removed. Most sites simply don’t need verification and should just accept my email/password information. I’d also be happy with using OAuth for identification only and providing my own password.
A large part of my complaint of OAuth isn’t against the system itself, but rather the primary providers: social websites. These are absolutely the wrong entities to be providing this type of service. Many of the issues could be overcome with a well designed provider who focuses on security. It should then be this provider which even Twitter and Facebook use to login. The dynamic now is totally wrong and that leads to a lot of the issues.
Terriffic article, most comprehensive I found, after >1 hour searching. Thanks. One question–couldn’t the token be made app-specific? E.g., if I use OAuth for Facebook to log in to sleaze.com, that token only works for sleaze.com.
(In case any interest, here is my own post on the topic–really doesn’t say anything different than here, just much more simplified: http://bit.ly/1fOhtGz.)
The tokens are app specific: each authorized app via Facebook will get its own token. The issue of security is that somebody with access to the Facebook account can still easily get access to all of those applications by simply getting a new token.
As a user trying to improve his password management I’m trying to understand the risks of OAuth,