My question is: Is it fine to build applications where the user login is completely handled by OAuth2 and services like that. That way we do not have to have our own password database for the users. How good this approach would be keeping in mind the user experience? Also would this approach be easy to implement the multi-factor authentication?
Is it fine to build applications where the user login is completely handled by OAuth2 and services like that.
If both the user and the service provider can trust the OAuth2 provider and if OAuth2 is implemented correctly it is fine. Note that this trust also includes privacy: the service provider can see which services the user is using. And there is no general rule if a service provider is trustable or not - it depends on the specific service provider and the specific use case. For example: NSA would likely not use Baidu (China) as OAuth2 provider.
That way we do not have to have our own password database for the users.
The use case of OAuth2 is not only third party provided authentication. It can also be used in-house to provide single sign on to various internal services. In this case you still have your own internal password database.
How good this approach would be keeping in mind the user experience?
In general single sign on and less passwords to remember provide a good user experience. But if you force the user to use an OAuth2 provider he does not like the experience will be bad. This can for example the case when you force privacy sensitive users to login with some social network provider even if these users specifically refused to use social networks so far for privacy reasons.
Also would this approach be easy to implement the multi-factor authentication?
Most large OAuth2 providers offer MFA already.
I think you are confusing "social login" with "OAuth". A social provider may or may not use OAuth. And an OAuth provider may or may not be a public IDP.
If the question is "Should I use social login". I would say... it depends on your security requirements. If you can accept the inherent risk (i.e. lack of identity proofing), it's awfully convenient for the user. And you don't have to build a password reset or other IDM flows. And you won't have to protect passwords (which are like toxic waste).
If you are using an external IDP (i.e. social login), you will rely on them to provide MFA (as suggested above).
If you want to deploy and operate your own identity provider, that uses OAuth (or more specifically OpenID Connect) and support multi-facator authentication... then you should check out the free open source Gluu Server.
I have rejected multiple services in the past because they only used only external SSO(single-sign-on)-services (especially only ones that are on my personal blacklist).
Why did they get on my blacklist:
- Facebook and similar for privacy reasons
- Requires a verified phone-number (for privacy reason, I only give my phone-number when there is a reason and just for login is not a valid reason)
- SSO-providers which repeatedly deleted/locked my account for no reason after a month (or suddenly required me to give them my full real name, address, photo (!), verifiable phone-number(!) and a scan of my passport (!)). I used the account for nothing else than for a simple product activation for a free(!) product and they locked it for "suspicious behavior". The most likely reason for this blocking was likely that I insert a fake name (why would they need my real one?) and that I didn't provide enough personally identifying information.
So you should check, if you are really OK with this. Also you should think about what you would/can do, if an important user gets blocked by your SSO-provider because they not only verify the password but they also decide whom they don't let in. Also think about the case, when there is an outage at the SSO-provider and your administrators/moderators/... needs access and you can't because of the outage or they are blocked.