Laravel 5.3 - Социальные логические сомнения

Я разрабатываю мобильное приложение и в настоящее время в зависимости от JWT для поддержания безгражданства API. API потребляется мобильными и веб-устройствами. Пользователи будут использовать свой адрес электронной почты и пароль для регистрации.

Мне присваивается возможность использования опции социального входа в этом API. Я хотел бы высказать свои следующие сомнения.

1) Когда используется Social Login, как я могу сгенерировать токен [как JWT], который будет храниться на стороне клиента? Этот токен должен отправлять со всеми последующими запросами после входа в систему.

2) Если социальные платформы не предоставляют/не могут использовать адрес электронной почты [который является одним из наших основных ключей], какую информацию я должен хранить?

Ответ 1

SHORT ANSWER

Вы должны привязать пользователя социального входа к вашей стандартной пользовательской таблице и сгенерировать токен (JWT), как вы уже делаете
Социальные логины всегда возвращают идентификатор, идентифицирующий пользователя в социальной сети. Во внешней таблице сохраните используемую социальную среду и социальную идентификацию, а также таблицу user_id из ваших основных пользователей.

ДОЛГОЙ ОТВЕТ

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

Основная таблица пользователей
Обычно у вас есть таблица пользователей, структурированная таким образом (упрощенная)

user_id
логин (электронная почта)
пароль
jwt_token

Когда пользователь вводит логин, вы собираетесь обновить поле jwt_token и вернуть его пользователю, чтобы потреблять ваши API.

Реализация социальных логинов
Хорошим подходом для добавления социальных логинов является создание новой таблицы social_logins, структурированной следующим образом (упрощенной)

социальная
social_id
user_id

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

Первое, что вам нужно сделать, это проверить, возвратил ли вам социальный адрес пользователя.

если возвращается электронное письмо, найдите пользователя с этим адресом электронной почты в таблице ваших пользователей и создайте запись в таблице "social_logins", создав связь с пользователем, используя поле user_id.
Если письмо пустое, вам нужно создать нового пользователя в таблице пользователя, создав "поддельный" адрес электронной почты (со стандартным методом - не случайным), а затем создайте запись social_login

Чтобы избежать создания двойных пользователей (разные адреса электронной почты), я всегда предпочитаю просить пользователя подтвердить его адрес электронной почты: с помощью этого простого вопроса вы можете отложить предыдущую проверку и уменьшить количество двойных пользователей. Итак, если социальный логин не возвращает вам адрес электронной почты, вы просто показываете пустое поле с просьбой заполнить его своим адресом электронной почты, который затем будет использоваться для поиска пользователя в таблице пользователей. Если вместо этого вы получили его, просто покажите пользователю одно и то же поле и попросите его подтвердить адрес электронной почты или изменить его, если он предпочитает использовать другой адрес или если он уже зарегистрирован в вашем приложении с другим адресом электронной почты.

Ответ 2

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

Используйте эти данные для регистрации пользователя в вашей собственной системе. Прикрепите также предоставленный токен доступа. В зависимости от разрешений, которые вы запросили, вы можете использовать токен для выполнения дополнительной операции в социальной платформе.

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

 {
   "sub": "userid",     //unique user id assigned in your system 
   "name": "User name"  //Name provided by social 
   "iss": "issuer",     //you are the issuer
   "exp": 1300819380,   //Expiration date
   "login":"facebook"   //login method used
  }

Если вы планируете использовать несколько систем аутентификации, таких как Google или Facebook, не используйте электронную почту как уникальный идентификатор, потому что она может отличаться для одного и того же пользователя. Для связывания учетных записей, которые пользователь имеет в разных сетях, вам понадобится дополнительный процесс регистрации. Например, позволяя пользователю установить идентификатор, который используется в другой системе, или просто запустить процесс регистрации в Твиттере, когда пользователь регистрируется в Facebook