Отказ от стандартной авторизации в пользу социальной

Уже достаточно давно многие сайты предоставляют наряду со стандартной авторизацией, авторизацию через социальные сети и веб-сервисы. Перед вами стоит выбор:

1. Пройти относительно длинный путь регистрации — ввод email/пароля/капчи и активация по email.
2. Просто нажать на иконку социальной сети, в которой у вас заведён аккаунт, и подтвердить доступ.

А почему бы вообще не отказаться от стандартного механизма регистрации? Кстати именно такой подход и реализован на веб-сервисе on{X} от Microsoft — авторизация только через Facebook.

Но не всё так радужно, как может показаться на первый взгляд. Выделим положительные и негативные стороны социальной авторизации с учётом того, что мы собираемся полностью отказаться от регистрации по комбинации email/пароль.

Достоинства:

• Быстрая авторизация на сайте.
• Данные о пользователе от провайдера авторизации.
• Отсутствие паролей.
• Отсутствие активации аккаунта.
• Единственная форма — форма авторизации.

Недостатки:

• Некоторые провайдеры авторизации не отдают email.
• Разный формат предоставляемых данных о пользователе.
• Предпочтения аудитории.
• Можно забыть через какой сервис проходил авторизацию.

С достоинствами этого подхода всё ясно. Нас же больше интересуют недостатки и пути их решения.

Недостатки

Некоторые провайдеры авторизации не отдают email

Да, самая важная информация, которую нам надо знать о пользователе, у некоторых провайдеров может быть недоступна. В частности Вконтакте и Одноклассники в общедоступном API не отдают его. Facebook и Google более лояльно относятся к email адресу и с помощью определённых разрешений успешно вернут вам эту информацию.
Решение:

1. Одно из популярных решений проблемы — просто спросить его у пользователя после авторизации. Это добавит дополнительный диалог и придётся делать процедуру активации.
2. В зависимости от целевой аудитории отказаться от провайдеров авторизации, которые не отдают email.
3. Не использовать электронный адрес. Опять же не везде можно так легко отказаться от практически единственного средства обратной связи с пользователем. Допустим соц. сеть Вконтакте использует для регистрации номер мобильного телефона. Тут нужно подумать о том — как пользователь восстановит доступ к сайту, если он удалит аккаунт в социальной сети.

Разный формат предоставляемых данных о пользователе

Иногда требуется знать о пользователе немного больше, чем просто идентификатор в соц. сети. К таким данным могут относиться: имя, фамилия, ник, пол, аватар, дата рождения. Так как протоколы OAuth и OpenID не предназначены для получения каких-либо данных о пользователе, то придётся использовать API каждого конкретного сервиса и возвращаемые данные будут везде разные. В частности провайдеры авторизации Google, Вконтакте, Facebook и Одноклассники предоставляют все перечисленные выше данные. Осталось их только обработать.
Решение: если очень нужны дополнительные данные о пользователе — сделайте их запрос у сервиса авторизации. Если нужно ещё более специфичные данные — попросите пользователя ввести их самостоятельно после авторизации.

Предпочтения аудитории

Ну, вот мы и добрались до самого проблемного вопроса — а не отобьёт ли такой отказ от стандартной регистрации вашу целевую аудиторию? Моё мнение по этому поводу такое: даже если человек наотрез не хочет проходить авторизацию через социальные сервисы, но альтернатив вашему сервису нет, то он в конечном итоге сдастся. Я же лично придерживаюсь такого алгоритма: если я планирую пользоваться каким-то конкретным сервисом в будущем, то я обязательно регистрируюсь там через логин и пароль. Если же на сайте не будет такой возможности, то я буду авторизоваться через соц. сети.
Даже если пользователя нет в социальных сетях, то у него по любому должен быть почтовый аккаунт gmail, mail.ru или других сервисов. Следовательно, случай, когда у пользователя просто нет ни одного аккаунта у предоставляемых сервисов авторизации, маловероятен.

Можно забыть через какой сервис проходил авторизацию

Если ваш ресурс даёт возможность авторизоваться через over9000 провайдеров, а у пользователя есть как минимум 2 аккаунта у этих провайдеров, то он может просто забыть каким конкретно способом он входил на сайт. В случае ошибки будет создана никому не нужная запись о новой регистрации в БД.
Решение: записать в cookies сервис авторизации и выделять его на странице входа. Возможно, это создаёт какую-то угрозу безопасности, но я не могу сходу придумать, как можно серьёзно этим воспользоваться.

Заключение

Идея отказа от обычной регистрации очень соблазнительна, но всё зависит от того сможете ли вы избавиться от описанных проблем.

P.S. Немного статистики от uLogin можно прочитать тут.