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:
- Integrate OAuth.
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:
- Two-factor authentication.
- Password recovery by phone.
- Backup e-mail account.
- Suspicious activity reports, like someone trying to access your account using Tor.
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:
- Google has the best implementation, which made it our first choice for testing (it helps that the majority of our users are using Google accounts). Overall, the experience was fluid and reliable.
- Twitter has never abandoned OAuth1 officially, and their adoption of the OAuth2 standard has been partial and slow. They also insist in not including a scope to retrieve the e-mail of the user, which is a major inconvenience and made us almost drop it from our login page. Instead, we had to include an e-mail confirmation step just for Twitter. Thanks, guys.
- Linkedin may return two different OAuth ids for the same user depending on the application that is asking. TL;DR if you are forced to change your Linkedin API key at any time in the future, your entire database of users will be lost.
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
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 are looking for conclusions:
- We still love OAuth, sort of, in a cyanide and happiness way. It's not perfect, but it lets us focus on real problems.
- If you can choose, go with OAuth2.
- Nothing will remove LastPass from our laptops, ever.
- Remember to have a working e-mail address firstname.lastname@example.org.