Предотвращение нескольких одновременных входов в систему с Cognito

Question

У нас есть приложение React Native, которое использует Cognito для аутентификации.Мы хотели бы предотвратить одновременный вход в систему одного и того же идентификатора пользователя с нескольких устройств.

Мы надеялись, что для этого сможем использовать триггер предварительной аутентификации Cognito.К сожалению, кажется, что мы не можем просто вызвать globalSignOut для пользователя, так как это не сделает недействительными токены, которые уже были выпущены и в настоящее время активны (см. https://github.com/amazon-archives/amazon-cognito-identity-js/issues/21#issuecomment-331472144).

Другая идея состояла в том, чтобы отклонитьВойдите в систему, если пользователь вошел в систему в другом месте. Но мы не можем найти надежный способ определить, вошел ли пользователь в систему. Мы можем увидеть, есть ли для этого пользователя действительные токены, но не связаны ли они с активным в данный момент.сеанс.

Мы также думали о поддержке нашей собственной БД активных сеансов, но нет триггера выхода, поэтому мы не будем знать, когда удалять сеанс из БД.

Answer 1

Вы можете использовать систему аутентификации токена,

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

, если какой-либо токен доступен для пользователя, что означает He /Она вошла в какое-то другое устройство, для этого случая вы можете запросить у пользователя, что Вы вошли в другое устройство ... Вы уверены, что хотите выйти из этого устройства? и после нажатия Да, вы можете удалитьвсе токены для этого пользователя.И выдайте новый токен.

AUTO LOGOUT : этот токен должен быть передан по всему бэкэнду, т. Е. В заголовках каждого маркера вызова API должен быть там ... идолжны быть проверены, прежде чем делать что-либо в фоновом режиме.если токен недоступен, бросьте 401 .В вашем приложении, если какой-либо API выдает 401 , это означает, что пользователь НЕАВТОРИЧЕН и должен выйти из системы.

или

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

или

имеет приемник уведомлений, который будет использоваться для выхода из системы при необходимости, так же, как и сокет.

Answer 2

Вы можете использовать UUID устройства, чтобы определить, является ли это тот же пользователь. Добавьте UUID к каждому заголовку запроса, чтобы записать его в БД, и тогда вы сможете делать то, что хотите.

Answer 3

Чтение ссылки, которую вы предоставили, система токенов / сеансов API кажется неисправной в дизайне уже долгое время.
Так что без собственной токен-системы внутри cognito у вас не будет надежных результатов, вероятно, по крайней мере втекущее состояние системы (поскольку хранилище заархивировано, владелец больше не будет его развивать).

То, что я предлагаю, - это собственное поле в таблице базы данных для пользователей, где каждый логин имеет честьсобственный токен.Второе собственное поле в той же таблице с отметкой времени, где сохраняется последний доступ.Если последний доступ старше заданного времени 30, 60 или 120 минут, любой пользователь выходит из системы.Если последний доступ моложе срока, то маска логина должна предоставить токен произвольного доступа, который сравнивается с токеном в базе данных:
- если токен доступа в базе данных слишком стар для активногосеанс, или просто токен доступа не сохраняется, тогда доступ может быть предоставлен, что означает, что вход выполнен успешно.
- сравнение текущего времени с отметкой времени, сохраненной в базе данных, для случаев, когда пользователи никогда не регистрировалисьпреднамеренно, но просто будучи отключенным или пассивным.Я думаю, что этот случай будет происходить регулярно, так что не исключение .
- выход из системы нажатием кнопки должен уничтожить токен доступа в базе данных, так что пользователь может сразу войти в систему с любого устройствадаже от другого до этого.
- если в базе данных существует действительный токен доступа, то новый доступ предоставляться не будет, и пользователю должно быть показано сообщение о том, что он должен сначала выйти из системы при другом входе в систему.
- токен доступа может храниться вместе с третьим собственным полем для идентификатора сеанса, чтобы сделать его более надежным и безопасным.При выходе из системы это поле сессии также может быть очищено.Токен сеанса можно скопировать из глобального сеанса, если требуется сохранить его в пользовательской записи.
- Любые проверки выполняются только при входе в систему, токены никогда не должны включаться на каждой странице.
- При активномВыйти из системы токены должны быть уничтожены, чтобы снова разрешить прямой вход в систему, иначе пользователям пришлось ждать макс.истекает срок для повторного входа в систему - по крайней мере, на другом устройстве, а не раньше.

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

Если вы предоставляете доступ-теканется на каждой странице, как предложено @Jadeep Galani, или в cookie-файле - кроме соответствующей проверки - вы также можете предложить кнопку для выхода со всех устройств.Это позволит пользователям в любой момент изменить логин, даже не выходя из системы на последнем использованном устройстве.Без маркера доступа на каждой странице или в файле cookie это общее решение для функции выхода из системы невозможно, поскольку доступ проверяется только при входе в систему, но не на всех страницах.

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