Our love-hate relationship with OAuth
A couple of years ago we integrated our login page at Koliseo using all the social networks that made sense, up to the point were we had to stop before hitting the paradox of choice. We ended up with this interface:
This covers the most common OAuth2 providers that we could think about, using email (GMail, HotMail and Yahoo) or social networks (Google+, Facebook, Linkedin or Twitter). Half of them are using OAuth2, the rest are still stuck with OAuth1.
These are our conclusions after debugging this feature to death.
We love OAuth2
OAuth2 is a bit too good to be true. If you were developing your own user authentication system, this is a non-exhaustive list of features you should consider fitting in:
- Database encryption for passwords, in which case you must choose your encryption algorithm. Be prepared for a couple of nights reading about the demise of MD5 or flavors of salt for your passwords.
- Password recovery via e-mail.
- E-mail warnings whenever the user changes their password.
- Detect when the same user has failed to log-in multiple times to display a captcha for a better entertaining experience.
Detect when a significant set of users are trying to log-in using the same (wrong) password in a short period of time, probably from a concrete set of IPs.
I'm no security expert, so probably I am forgetting something. But hey, you have an alternative:
Yup. Man, do we like shorter TODO lists.
Extras included with OAuth
If you are opting for OAuth, your friendly authentication provider may be including the following extras for free:
Also, you are contributing to a more secure Internet: less user accounts means less security holes, because - breaking news - people reuse passwords for the hundreds of websites they visit.
Little does it matter that you are encrypting and salting your passwords if someone else is storing the same passwords in a text file in a shared Windows folder. OAuth does not remove the need to secure your system (SSL, XSS, Content Security Policy all apply the same) but anything password-related suddenly becomes someone else's problem.
Not everyone is happy with this system, and we got a 1% of users that didn't have or didn't want to login using any of these providers. We were OK with that; others may consider Mozilla Persona to be open to everybody.
We also hate OAuth
You know the joke, right? When you are integrating six different providers, you have seven different problems:
OAuth is complicated
For all we tried, nothing saved us from was^H^H^H investing significant time reading the standard. We needed to at least get the concepts, the different authorization workflows and figure out the right integration for what we intended to do. For anybody looking to get introduced into OAuth, we can recommend the excellent OAuth bible by the Mashape guys.
The Bible didn't exist when we implemented this, so we did it the hard way: eat RFC, bitch.
OAuth adds new security holes
The following is the list of apps that I had authorized at the time of this writing. All providers like Google or Twitter have a page like this.
How often do I check this page? Believe it or not, once a year I empty this list thoroughly. With a less paranoid user it would be quite easy to introduce an entry that keeps their personal data hacked for the foreseeable future.
Steal the user password and use it to authorize an app, for example TweetDeck accessing a hacked Twitter account. Now the account will remain hacked even if the user changes their password, as long as they don't revoke the authorization.
But we are still happy
If you want to give it a spin, you can test our implementation. Comments and feedback are welcome!