When your site needs user registering (e.g. to track some activity, perhaps, learning progress as in my case) - you probably first implement simple login/password system.
You soon found that:
- some users directly ask to provide OAuth login via Facebook or Twitter for example - for they don't like remembering another one password or sharing email
- also it is not that easy to manage login/password system as you need to implement "forget password" emailing and probably password cleverness check.
But which OAuth to choose. Stackoverflow, for example, had over dozen options. My own site (codeabbey) uses three:
Of course some people don't like OAuth and suspect it can steal their accounts. For this it is good to have some explanatory text near login form. Really it is much safer for users (and easier for you) because your site doesn't need to store any emails, hash passwords and thus no secrets could be spilled even if your site is hacked.
How to decide?
There are at least two sides of the question:
- What method is most convenient for your typical users
- What method is not too inconvenient for you as site maintainer.
Below I share my thoughts and observations for 3 popular methods - Facebook, Gmail, Github. Hopefully someone can share few others, e.g. about Twitter.
The social network with over 2 billion "monthly active" users, so (with earth population at 7 billion) great chance is you users have FB account.
Unless the site is for some location-specific users - e.g. in my native country FB is not the most popular social network.
With some additional permits you'd be able to get url to user's FB account also.
Disadvantage over years of using it, there were several times when FB sends warnings about API update and deprecation. Last email was about "critical error on your site" without comprehensible explanation (it appeared FB login won't work from plain http version of site nowadays, but that's not bug, rather their decision). Thus it requires some care in some unpredictable moments. It's a bit annoying - no one wants users to become suddenly unable to use their accounts - and it may happen that over years you forgot the details of implementation and need time to recollect.
Also it's API is a bit more weird, especially JS-backed form. Not sure if anything was improved.
Gmail
Google also has comparable user base. It never required any care after years. It just works.
Disadvantage there is no link to any social profile (even while Google+ was working it was useless). There is some API which can give google user identifier / email additionally.
GitHub
This is of course specific - good if your users are related to IT, software development etc.
But you get link to github profile at once. I never needed to improve or change anything in years after I added it to site. Also it is (my personal opinion) slightly easier to implement then both others.
OpenID
It was one of the first providers, as I remember (perhaps before OAuth itself), and it still has a lot of accounts. However, before I decided about adding this to site, I've seen StackOverflow ending using it - and this made me thought that I can spare efforts and don't try this.
Seemingly rival identity services provided by social networks made this option barely useful and it seems like becoming dying / marginal slowly.
Top comments (4)
OpenID is a standard and currently, OpenID Connect exists as an extension to OAuth 2.0.
Red Hat Single Sign on uses it for example. Very good standard for now and for in the future.
For Apple users, the Sign In with Apple is a great way to log in to systems.
I think it is using some kind of OpenID/OpenID Connect implementation.
Personally I would never build in social login and go for my own login system or OAuth2 implementation.
Facebook and Google are both advertising platforms.. so I would feel shame when I would offer people those options. Plus it offers not a single benefit for you or your user...well except one password less to remember.
It is also fairly easy to build such a login system yourself.
You are clever - that is a good point :) but we most people are, well, general - and choose for convenience, without thinking of this problem...
It's fairly easy to build easy system. I believe many of us did this many times. However consider that:
it has some points for getting head-ache. so I understand why some sites (like dev.to) don't use own login/password system.
Password restore system is also not that hard.
If you need to do this and are not allowed to store someones email address, for example when it is not possible to ask the user if this is okay, then you could add something like the Google Authenticator or Last Pass authenticator and add a One-time password as a recovery means.
Captcha has been improved and is called re-captcha and is also fairly simple to include. That and login throttling can solve most of your problems. This problem has been solved many times and there are many resources on how to do this.
Protecting password hashes OR protecting anything in general is always a problem, BUT if you have trouble grasping how to protect sensitive data, then you probably should not be implementing anything on your own. Protecting hashes, in my opinion, could be done in a well protected database. And even if they get the database, make sure you have used BCRYPT or ARGON2 as a hasher, so that it becomes expensive to steal them.
Security is risk assessment. If you are a small fish, do not expect people to spend millions to hack you. So for every problem, asses it to understand how your infrastructure should be laid out to secure the data.
If you ask for consent and be transparent about what you store, for what reason.. then you will comply. Do not store more than you need. Keep the footprint low. If you would only store an email-address for account recovery or contact information, then it should be fine. As long as you tell them what you are storing.
Well, I don't mean it is very hard. But as usually, not doing this at
all is easier. That is my point :)
Note that by GDPR, I think, this probably should be stored on servers in the same region where user resides. That may be painful. Though workaround is to store only hash of email and then ask for user to enter it (and compare hash) when user wants password reminder...