March 11, 2013 at 11:34Refusal of standard authorization in favor of social
For a long time, many sites provide along with standard authorization, authorization through social networks and web services. You have a choice:
And why not abandon the standard registration mechanism at all? By the way, this is 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 might seem at first glance. We highlight 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:
The merits of this approach are clear. We are more interested in the shortcomings and ways to solve them.
Yes, the most important information we need to know about the user may not be available for some providers. In particular, Vkontakte and Odnoklassniki in the public API do not give it away. Facebook and Google are more loyal to the email address and with the help of certain permissions they will successfully return this information to you.
Decision:
Sometimes you need 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 designed to receive any user data, 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 of the above data. It remains only to process them.
Solution: if additional data about the user is really needed - make a request from the authorization service. If you need even more specific data, ask the user to enter it yourself after authorization.
Well, here we got to the most problematic question - but will such a rejection of standard registration beat your target audience? My opinion on this subject is this: even if a person flatly does not want to go through authorization through social services, but there are no alternatives to your service, then he will eventually give up. I personally adhere to such an algorithm: if I plan to use any particular service in the future, then I will definitely register there via login and password. If the site does not have such an opportunity, then I will log in through the social. network.
Even if the user is not on social networks, then he should have a gmail, mail.ru or other services email account. Therefore, the case when the user simply does not have a single account with the provided authorization services is unlikely.
If your resource makes it possible to log in through over9000 providers, and the user has at least 2 accounts with these providers, then he can simply forget exactly how he entered the site. In case of an error, an unnecessary record will be created for anyone about a new registration in the database.
Solution: write the authorization service in cookies and select it on the login page. Perhaps this poses some kind of security risk, but I can’t immediately figure out how to take this 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 a relatively long way of registration - 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.
And why not abandon the standard registration mechanism at all? By the way, this is 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 might seem at first glance. We highlight 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:
- Quick authorization on the site.
- User information from the authorization provider.
- Lack of passwords.
- Lack of account activation.
- The only form is the authorization form.
Disadvantages:
- Some authorization providers do not send email.
- Different format of user data provided.
- Audience preferences.
- You can forget which service went through authorization.
The merits of this approach are clear. We are more interested in the shortcomings and ways to solve them.
disadvantages
Some authorization providers do not send email
Yes, the most important information we need to know about the user may not be available for some providers. In particular, Vkontakte and Odnoklassniki in the public API do not give it away. Facebook and Google are more loyal to the email address and with the help of certain permissions they will successfully return this information to you.
Decision:
- One of the popular solutions to the problem is simply to ask the user after authorization. This will add an additional dialogue and have to do the activation procedure.
- Depending on the target audience, refuse authorization providers that do not send email.
- Do not use email address. Again, not everywhere it is so easy to refuse almost the only means of user feedback. Let's say social. Vkontakte network uses a 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 need 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 designed to receive any user data, 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 of the above data. It remains only to process them.
Solution: if additional data about the user is really needed - make a request from the authorization service. If you need even more specific data, ask the user to enter it yourself after authorization.
Audience Preferences
Well, here we got to the most problematic question - but will such a rejection of standard registration beat your target audience? My opinion on this subject is this: even if a person flatly does not want to go through authorization through social services, but there are no alternatives to your service, then he will eventually give up. I personally adhere to such an algorithm: if I plan to use any particular service in the future, then I will definitely register there via login and password. If the site does not have such an opportunity, then I will log in through the social. network.
Even if the user is not on social networks, then he should have a gmail, mail.ru or other services email account. Therefore, the case when the user simply does not have a single account with the provided authorization services is unlikely.
You can forget which service went through authorization
If your resource makes it possible to log in through over9000 providers, and the user has at least 2 accounts with these providers, then he can simply forget exactly how he entered the site. In case of an error, an unnecessary record will be created for anyone about a new registration in the database.
Solution: write the authorization service in cookies and select it on the login page. Perhaps this poses some kind of security risk, but I can’t immediately figure out how to take this 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 .