Я использую JWT для аутентификации. Однако я не хочу, чтобы пользователь регистрировался с нескольких устройств. Как это обеспечить?Разрешить вход с одного устройства одновременно в NodeJS
Прямо сейчас - все, что я могу придумать, - это сохранить JWT в БД и затем проверить, существует ли он. И если он существует, то каково время его создания. Если слишком много времени - мы идем и регенерируем токен и переходим к второму устройству.
Это в значительной степени ваш единственный вариант, JWT довольно не имеет гражданства по назначению. Аналогично тому, как вы не можете выполнять отключение на стороне сервера без аналогичной техники
Как отмечает друг, хранение JWT в одиночку недостаточное. Что вам нужно сделать, так это убедиться, что в следующий раз, когда пользователь будет запрашивать логин, у них еще нет выпущенного им JWT.
Переход через поток для полноты:
Случай 1: Пользователь не зарегистрирован в любом месте. В этом случае JWT выдается и сохраняется. Возможно, в записи пользователя для легкого извлечения.
Случай 2: Пользователь пытается войти на другое устройство. Если вы заставляете их явно выходить из первого устройства или делать это за них, вы должны отправить этот сохраненный токен в список отозванных токенов. Логика проверки маркера должна учитывать этот список при определении того, является ли токен действительным или нет.
/* Дальнейшее уточнение */
Я чувствую себя немного более подробно могут быть полезны для людей, так что я собираюсь идти в реализацию немного.
** Неидентифицированные запросы **
Это не должно измениться, но стоит отметить, что я предполагаю, что у вас есть маршруты, которые требуют проверки подлинности, а также запросы на тех маршрутах, которые не включают в себя активный и действительный JWT получите отклонение с помощью 401 (и, возможно, указав URL-адрес для входа в систему).
Войти
Войти логика всегда включает в себя поиск пользователей, так, как описано выше, поток в этом приложении должен включать этот поиск, но перед входом пользователя в приложении, которое будет проверять, есть ли уже назначенный токен пользователю, который истек.
Если для пользователя уже не назначена маркер, тогда проверьте учетные данные, как правило, вы создадите JWT (с заголовком exp, указывающим время истечения срока полезной нагрузки), сохраните этот токен в пользовательском документе/запись для дальнейшего использования.
Если - назначенный токен, который также не выполнен, вам необходимо либо вывести пользователя из другого устройства (более того, на секунду), и записать его на текущее устройство, либо вы должны отклонить попытку входа в систему и оставить человека вне нового устройства. Я думаю, что прежний подход более удобен для пользователя, но зависит от потребностей вашего приложения.
Выход
С JWT, единственный способ гарантировать, что пользователь не может использовать выданный маркер будет либо включать время истечения срока действия (Exp) в полезной нагрузке, а также использовать верификатор, который проверяет, что, или знать на сервере, что токены больше не действительны и проверяют их. Самые надежные решения делают оба.
Итак, предполагая, что вы обрабатываете истечение, уже явная функция выхода из системы будет обрабатываться путем создания списка отозванных токенов. Например, если вы используете MongoDB, вы должны создать коллекцию для их хранения. В идеале вы также установите TTL для каждого из них, который будет установлен в какой-то момент после истечения срока действия, так что Mongo вытеснит жетоны, которые в ином случае истекли, чтобы сэкономить время и пространство.
Если вы выполняете автоматический выход из системы при новом запросе на вход, вы попадете в эту логику, чтобы поместить старый токен в список отозванных токенов, когда вы сохраняете новый токен в документе пользователя.
Маршрут выхода из системы также должен быть доступен аутентифицированным пользователям, чтобы явно выйти из системы, если они захотят, независимо от того, выполняется ли автоматический выход из системы или нет.
идентифицированные просит
К этому моменту вы должны быть основания полагать, что пользователи могут войти только на одном устройстве. Однако вам также необходимо убедиться, что они не пытаются сделать запрос с отмененным токеном.
Ваше обобщенное промежуточное ПО для обеспечения безопасности маршрута затем должно также проверить отозванный список токенов, чтобы узнать, включен ли токен, предложенный клиентом, в указанном списке после проверки, чтобы он не был истек (поскольку истечение может быть проверено после проверки, сохраняя обратную связь с БД.
Я не думаю, что вы хотите сохранить токен JWT в своей БД, а скорее только тот факт, что этот пользователь вошел в систему и когда их последняя активность была. здесь все токены JWT для данного пользователя не совпадают (так как они могут иметь информацию о времени в них), поэтому вы не ищете точное совпадение токенов JWT. – jfriend00
Я также думаю, что у вас может быть проблема выхода из системы, потому что если вы хотите заставить предыдущего пользователя выйти из системы, когда новый клиент хочет войти в систему, вам придется как-то сообщите, что их токен JWT больше не действителен. Это, возможно, случай, когда серверный характер JWT не помогает вам. С традиционной схемой сеанса вы просто удалите объект сеанса пользователя на сервере, чтобы вывести их из системы. – jfriend00
@ jfriend00 theres поле, созданное JWT, называемое iat в полезной нагрузке. Это фактически имеет информацию о времени –