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:
- An interface to modify your password, maybe with a password strength meter in JavaScript.
- 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:
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](http://www.mozilla.org/en-US/persona/) to be open to everybody.
We also hate OAuth
You know the joke, right? When you are integrating four different providers, you have five different problems. Each provider implements things in a slightly different way.
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: by eating RFC.