Denial of standard authorization in favor of social
Already for a long time, many sites provide along with standard authorization, authorization through social networks and web services. You have a choice:
Why not abandon the standard registration mechanism at all? By the way, this is exactly the approach that was implemented on the on {X} web service from Microsoft - authorization only through Facebook.
But not everything is as rosy as it may seem at first glance. Let us single out the positive and negative sides of social authorization, taking into account the fact that we are going to completely refuse to register using the email / password combination.
')
Advantages:
Disadvantages:
With the merits of this approach, everything is clear. We are more interested in the shortcomings and their solutions.
Yes, the most important information that we need to know about the user, some providers may not be available. In particular, Vkontakte and Odnoklassniki do not give it to the public API. Facebook and Google are more loyal to the email address and with certain permissions will successfully return this information to you.
Decision:
Sometimes you want to know about the user a little more than just an identifier in the social. network. Such data may include: name, surname, nickname, gender, avatar, date of birth. Since the OAuth and OpenID protocols are not intended to get any data about the user, you will have to use the API of each specific service and the returned data will be different everywhere. In particular, the authorization providers Google, Vkontakte, Facebook and Odnoklassniki provide all the data listed above. It remains only to process them.
Solution: if you really need additional data about the user - make them a request from the authorization service. If you need even more specific data - ask the user to enter them yourself after authorization.
Well, so we got to the most problematic question - would such a refusal from the standard registration discourage your target audience? My opinion on this matter is: even if a person does not want to pass authorization through social services, but there is no alternative to your service, he will eventually give up. I personally adhere to this algorithm: if I plan to use any particular service in the future, then I will definitely register there using a login and password. If the site does not have such an opportunity, then I will log in via social. network.
Even if the user is not in social networks, then he should have a mail account gmail, mail.ru or other services. Therefore, the case when the user simply does not have a single account with the provided authorization services is unlikely.
If your resource gives you the opportunity to log in through over9000 providers, and the user has at least 2 accounts with these providers, then he may simply forget in what way he entered the site. In the event of an error, an entry about the new registration in the database will be created for no one
Solution: write an authorization service in cookies and select it on the login page. Perhaps this creates some kind of security risk, but I can't figure out how to take it seriously.
The idea of ​​abandoning the usual registration is very tempting, but it all depends on whether you can get rid of the problems described.
PS Some statistics from uLogin can be read here .
- Go through a relatively long registration path - enter email / password / captcha and activate by email.
- Just click on the icon of the social network in which you have an account, and confirm access.
Why not abandon the standard registration mechanism at all? By the way, this is exactly the approach that was implemented on the on {X} web service from Microsoft - authorization only through Facebook.
But not everything is as rosy as it may seem at first glance. Let us single out the positive and negative sides of social authorization, taking into account the fact that we are going to completely refuse to register using the email / password combination.
')
Advantages:
- Fast authorization on the site.
- User data from the authorization provider.
- No passwords.
- No account activation.
- The only form is an authorization form.
Disadvantages:
- Some authorization providers do not give email.
- Different format of user data provided.
- Audience preferences.
- You can forget through what service passed authorization.
With the merits of this approach, everything is clear. We are more interested in the shortcomings and their solutions.
disadvantages
Some authorization providers do not give email
Yes, the most important information that we need to know about the user, some providers may not be available. In particular, Vkontakte and Odnoklassniki do not give it to the public API. Facebook and Google are more loyal to the email address and with certain permissions will successfully return this information to you.
Decision:
- One of the popular solutions to a problem is simply to ask the user after authorization. This will add an extra dialog and have to do the activation procedure.
- Depending on the target audience, refuse authorization providers that do not give email.
- Do not use email address. Again, it is not everywhere that it is so easy to abandon almost the only means of user feedback. Suppose social. Vkontakte network uses mobile phone number for registration. Here you need to think about how the user will restore access to the site if he removes the account on the social network.
Different format of user data provided
Sometimes you want to know about the user a little more than just an identifier in the social. network. Such data may include: name, surname, nickname, gender, avatar, date of birth. Since the OAuth and OpenID protocols are not intended to get any data about the user, you will have to use the API of each specific service and the returned data will be different everywhere. In particular, the authorization providers Google, Vkontakte, Facebook and Odnoklassniki provide all the data listed above. It remains only to process them.
Solution: if you really need additional data about the user - make them a request from the authorization service. If you need even more specific data - ask the user to enter them yourself after authorization.
Audience preferences
Well, so we got to the most problematic question - would such a refusal from the standard registration discourage your target audience? My opinion on this matter is: even if a person does not want to pass authorization through social services, but there is no alternative to your service, he will eventually give up. I personally adhere to this algorithm: if I plan to use any particular service in the future, then I will definitely register there using a login and password. If the site does not have such an opportunity, then I will log in via social. network.
Even if the user is not in social networks, then he should have a mail account gmail, mail.ru or other services. Therefore, the case when the user simply does not have a single account with the provided authorization services is unlikely.
You can forget through what service passed authorization
If your resource gives you the opportunity to log in through over9000 providers, and the user has at least 2 accounts with these providers, then he may simply forget in what way he entered the site. In the event of an error, an entry about the new registration in the database will be created for no one
Solution: write an authorization service in cookies and select it on the login page. Perhaps this creates some kind of security risk, but I can't figure out how to take it seriously.
Conclusion
The idea of ​​abandoning the usual registration is very tempting, but it all depends on whether you can get rid of the problems described.
PS Some statistics from uLogin can be read here .
Source: https://habr.com/ru/post/172205/
All Articles