Аутентификация через соц. сети, что делать?

Question

[Алекс]

Доброе утро!
Для обучения, решил написать класс для аутентификации через соц. сети.
С oauth разобрался, api тоже.

Возник следующий вопрос:
К примеру на сайте есть зарегистрированный пользователь с почтой [e-mail].
Спустя какое то время, этот пользователь решает зайти с помощью соц. сети, скажем vk.com.
О нажимает кнопку, проводим все действия и получаем данные из vk.

{
    id: 1,
    first_name: "Name",
    last_name: "Last",
    email: "[e-mail]"
}

И тут у меня возник вопрос, как логически верно объединить аккаунт который имеется на сайте с аккаунтом из соц. сети.
Понятно, что добавляем в БД vk.id
Сейчас у меня идет проверка в БД пользователя по email, если таковой находится, то пускаем на сайт. Мне кажется не слишком безопасный подход, может я себя накручиваю?

Answer 1

[Иван Никитин]

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

Answer 2

[Тимофей]

Тут важный момент есть: некоторые соцсети не дают доступа к мылу (например, VK). Да и может быть ситуация, когда разное мыло на соцсети и на сайте, но пользователь один. Лучше после того, как была произведена авторизация у провайдера, спрашивать e-mail (а лучше и пароль тоже) явно, но если провайдер предоставил e-mail, то просто подставлять его в соответствующее поле в форме. Если пытаешься использовать существующее мыло, то выдавать ошибку и предлагать сначала войти, а потом привязать аккаунт в личном кабинете (типа как на хабре).
Ну а в базе хранить пары провайдер-UID либо прямо в поле у пользователя, либо в отдельной таблице.

Comments

[Pablo]

На самом то деле, ВКонтакте выдает email пользователя, если он это разрешил. Для этого достаточно выполнить авторизацию с правами scope=email, после успешной авторизации, json ответ помимо access_token, expires_in и user_id будет еще содержать поле email.

[Тимофей]

Павел Громадчук: но тем не менее учесть сценарий, что пользователь не хочет раскрывать свой e-mail по определенным причинам, тоже нужно на мой взгляд. Учитывая еще тот факт, что у многих почты могут отличаться. А подход с идентификацией по uid вместо e-mail позволит справится с этой ситуацией.

[Sergej]

Все соц. сети дают email, без исключения.
Если у пользователя что то спрашивать после нажатия кнопочки - "войти через vk" - то нафига оно вообще надо?
Вы хоть раз делали с нуля, аутентификацию через классическую четверку (vk, google, fb, twitter) ?

типа как на хабре

- нет такого на ТМ. У них общий вход через любую соц. сеть, определение по email.
Сам лично заходил через все соц. сети которые они предлагают.

Ну а если пользователь не хочет раскрывать свой email, то пусть идет смотреть телевизор.
Т.к. регистрация на сайте, все равно будет по email.
Сейчас все более менее крупные проекты используют пару email/пароль.
email - это ваш уникальный номер.

[Sergej]

Тимофей: Вариант когда надо указывать email, возможен если на сайте делают не oauth а openapi

[Тимофей]

Иван: возможно, на coub как раз значит openapi используется (или раньше использовался, когда я там через контакт регистрировался) - там у меня почту спросили. В VK я, видимо, scope как раз не прописал, так что мыла там в данных пользователя не появилось (в ФБ и твиттере есть) - надо будет попробовать.
А почему бы не спросить пользователя e-mail? Просто, как я и написал, вставлять в поле по умолчанию мыло от провайдера, а если надо, то пользователь изменит.

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

Я не говорю, что пользователь не должен раскрывать e-mail - я говорю о том, что он может быть не тем, на который зареган акк у данного провайдера. У меня, например, есть почта "для спама", "для работы" и личная) Естественно, сайту я бы скормил почту для спама, хотя в Facebook я зарегистрирован по личной. И мне либо отказываться от авторизации через фб, либо получать спам на личную почту отовсюду, где я зарегистрирован. К тому же как быть, если уже есть учетка, я нажал на вход через, скажем, VK и получилось, что у меня 2 аккаунта? Объединить их уже не получится. А если спросить почту, то можно будет указать ту, которая уже зарегистрирована на сайте, увидеть сообщение, что я уже тут есть, авторизоваться по паролю и привязать аккаунт.

[Sergej]

Тимофей: Если у пользователя спрашивать email, то проще не делать oauth, а просто попросить заполнить 2 поля - email/password.

Если аккаунт уже есть, и он совпадает с email, то все хорошо, если email не совпадает, то логично - чт вы делаете еще один аккаунт.
К примеру такое у меня получилось с fishki.net

[Тимофей]

Иван: ну так я и предлагаю решение проблемы - автозаполненное поле с возможностью изменить e-mail. Вводить в простейшем случае ничего не надо, только нажать на одну кнопку для отправки формы и все. Такой компромисс для решения ряда проблем, на мой взгляд вполне оправданный.