На данный момент идентификация авторизованного пользователя через социальные сети работает следующим образом. Из социальной сети берется почтовый адрес, потом сверяется в таблице, если есть совпадение, значит вход в этот аккаунт, в противном случае, создаётся новый аккаунт с этой почтой. Но в связи с этим есть достаточно важные потенциальные проблемы. Первая проблема: если пользователь Facebook изменит почту, то при логине, он попадет в новый аккаунт, а не в свой старый, так как почты не будет в БД. Вторая проблема: некоторые социальные сети не выдают вообще почту, такая как Твиттер, к примеру, или Фейсбук если регистрация через мобильный телефон. А заставлять клиента при входе делать проверку и вводить почтовый адрес, если внешний провайдер не предоставил, не очень хочется. После множества статей, так и не понял какой способ самый оптимальный и лучший. Есть на данный момент такой вариант возможной реализации: полностью отвязаться от социальной почты и не использовать ее. А делать привязку только по ID пользователя из социальной сети. Если в моей таблице нет пользователя с таким социальным ID и этот ID не привязан к какому-то существующему аккаунту, как дополнительный способ входа - новый пользователь. То бишь, оставить такие способы регистрации/входа: 1. Через почту/пароль 2. Входы через внешних провайдеров И в дополнении, после входа в систему, в настройках аккаунта, пользователь может привязать ID социальной сети (хоть всех сразу). И если пользователя с таким социальным ID ещё нет в базе и он ещё нигде не привязан, значит он привязывается к текущему аккаунту (который может быть создан через почту/пароль, или другой социальный провайдер, не важно). И пользователь может входить в этот же аккаунт несколькими способами (в зависимости, какие способы он привязал, включая почту/пароль, если отдельно почту привязал). Такая реализация хорошая или имеет подводные камни? Большой плюс в том, что по сути при социальных логинах совсем не нужен будет email, только ID для идентификации. И не важно, даст ли социалка почту или нет, сменит почтовый адрес или нет, тоже это уже не моя проблема будет, ведь ID не меняется никогда. А если пользователь к своему аккаунту захочет привязать почту/пароль, как допольнительный вход, то ему придется ввести уникальную почту, даже если Гугл/Фейсбук ее предоставил (так как в этом способе почты от социалок игнорируются). Пример этой реализации: Пользователь первый раз зашёл через Google (зарегистрировался). Потом есть несколько вариантов событий: 1. Если пользователь зайдет дальше из Фейсбука, то это будет новый аккаунт, даже если почта совпадает с почтой Гугла (так как нет привязки по почте). 2. Если до первого входа через ФБ, сделает в профиле текущего аккаунта привязку к Фейсбук, то после дальнейшего входа через Фейсбук будет попадать в текущий аккаунт, в котором выполнил эту привязку, а не в новый, несмотря на почту и все такое. 3. Если игрок потом добавит способ входа "почта/пароль", то будет попадать через указанную почту/пароль в этот же аккаунт. Это хороший способ реализации или всё-таки первый, который с простой привязкой по почте, лучше?
Лучше делать по уникальному ID, он не будет изменен в отличии от почты и/или других данных. Специальный айди можно занести в отдельную ячейку таблицы базы данных, с указанием уникального кода соц-сети, например: fb, ok, vk и т.п., а это в свою очередь и избавит от массы проблем. Пускай пользователь хоть пол меняет, а попадать будет на свой аккаунт.
Спасибо за оперативный ответ. Сколько не читал про реализации SSO, не находил ни разу, что бы кто то так реализовывал, обычно только по email социалок биндяд профили, не используя ID провайдеров. Поэтому и сомневался, а правильно ли вообще так делать. Да, я так и планирую сделать. В таблице юзеров добавить поля: google_id, facebook_id. А если пользователь захочет связать два разных социальных профиля (или даже ввести почту/пароль как дополнительных тип входа) в один аккаунт, то предварительно он должен будет зайти в целевой аккаунт и в настройках профиля привязать еще одну соц сеть, если она еще не имеет аккаунта (не привязана). Тогда в таблице users добавиться ID в {provider}_id. И только тогда после логина, если запись google_id == id найдена привязанная, то вход в этот аккаунта. В противном случае создается новый аккаунт с google_id, если до этого не был никуда привязан. Верная логика?
лучше не доп поля в таблице - а доп таблицу user_id - 1 social_id - 3213231313211 social_provider - VK тогда можно будет легко расширяться на любые соцсети