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.
