История вопроса

С момента появления возможности генерации контента сайта на лету, возникла необходимость идентификации посетителя, т.е. необходимость отличить одного посетителя от другого, дабы показывать одному одну а другому другое. Далее возникает желание скрыть определенную информацию от чужих глаз в неком приватном пространстве. Проблема была решена.

Алгоритмов идентификации посетителя существует множество и выдумывать их можно бесконечно. Правда ни один из них не дает стопроцентной гарантии. В конечном итоге самый простой и старый - это использование файлов cookie.

Авторизация на сайте

Лет 10 назад авторизация пользователя на сайте заключалась вводе логина и пароля в форму на сайте. Сравнивая эту пару с данными в базе данных сайта - можно найти пользователя и сохранить его идентификатор в сессии или в тех же куках. Предварительно конечно пользователю необходимо было пройти процедуру регистрации - т.е. выбрать тот самый логин и пароль и передать его на сайт через другую форму.

Данный способ идентификации элементарен в реализации и накрепко прижился в веб-среде. Однако он абсолютно неудобен для среднестатистического пользователя. Необходимо регистрироваться на каждом сайте, либо использовать один пароль, либо где-то хранить несколько, каждый раз заполнять анкеты, подтверждать емейл и т.д. Масса однотипных действий зачастую отталкивали человека от регистрации. Для владельцев сайтов это конечно являлось определенной проблемой. Энтузиастами предпринимались попытки решить данную проблему посредством создания децентрализованной системы серверов выдающих информацию по идентификатору пользователя т.н. OpenId, однако эта система по каким-то не получила широкого распространения. Возможно как раз потому, что к этому времени все большее распространение получили социальные сети.

Что же дают соцсети?

А вот что. В настоящее время подавляющее большинство людей так или иначе связанных с интернетом имеют аккаунты в одной или нескольких социальных сетях, при том зачастую в аккаунте соц-сети содержатся некоторые данные о пользователе, как минимум адрес почты, максимум вся возможная информация, включая телефон и домашний адрес.

Не вдаваясь в подробности можно сказать, что на настоящий момент большинство крупных соц-сетей предоставляют программистам возможность использовать базы данных своих пользователей для авторизации на своих сайтах. Сайт может запросить от соц-сети определенную информацию, при этом владелец аккаунта решает давать доступ сайту к своим данным или нет. В подавляющем большинстве случаев для процедуры авторизации используется протокол oAuth2.0.

Удобно, но не просто.

Итак, программист может инициировать процедуру авторизации и в конечном итоге получить от соц-сети данные о пользователе которые тот разрешить передать сайту. Эти данные можно сохранить в базе данных сайта, можно каким либо другим образом использовать для идентификации. Пользователь ничего не вводит, максимум что ему потребуется - это авторизоваться на сайте самой соц-сети. Процедура абсолютно безопасна. Удобно. Но несмотря на описанный алгоритм авторизации реализация его у разных соц-сетей немного отличается. Разные названия переменных, разные типы запросов, ну и остальное по мелочам. Получается, что  необходимо для каждой соц-сети описать свой алгоритм, немного отличающийся от других. Неудобно. При том все процессы завязаны на “приложение” регистрируемое в соц-сети, приложение завязано на конкретный адрес сайта.  При использовании dev версии сайта это вообще становиться проблемой, поскольку адрес dev версии может не совпадать с адресом рабочей версии сайта.

Все это чрезвычайно усложняет применение метода авторизации через соц-сети на сторонних сайтах.

Брокеры авторизации

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

uLogin

https://ulogin.ru/

Вся работа по интеграции с данным сервисом заключается в подключении JS скрипта и вставке в нужное место сайта специального HTML кода. В этом самом месте будут отображены иконки выбранных программистом соц-сетей.

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

В скрипте который обрабатывает эту страницу сайта программист может обратиться к серверу uLogin для получения данных о пользователе и использовать эти данные по своему усмотрению.

Схема интеграции такова, что ее можно сделать не 100% переносимой между сайтами, объединив в некие модули или компоненты.

Итог

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