Раздвижное окно с истекающим токеном JWT Refre sh

Question

У меня работает веб-сайт + нативные приложения, которые взаимодействуют через HTTPS с моим бэкэндом. Должны быть выполнены следующие требования:

1. Раздвижная сессия на сайте. Это означает, что если пользователь взаимодействовал с сайтом в течение последних XX минут, он не должен выходить из системы
2. Запомнить меня на сайте. Если этот флажок установлен, пользователь не должен выходить из системы (или после очень длительного времени)
3. Пользователь не должен выходить из приложения в приложении
4. Доступ может быть отменен либо пользователем, либо пользователем. пользователь (в данный момент зарегистрирован) или указанные c события (смена пароля).

В настоящее время у меня есть следующее: Конечная точка маркера refre sh генерирует JWT, когда пароль ha sh и имя пользователя совпадают в базе данных. Каждый refre sh токен имеет jti, который хранится в базе данных, а также срок действия (только для очистки БД), device_id и отмененный флаг. Другую конечную точку можно получить с помощью токена refre sh, который возвращает токен доступа JWT. Токен доступа действителен в течение 15 минут. Маркер доступа не может быть отозван.

Мои проблемы возникают с требованием 1. Я не хочу, чтобы пользователь повторно аутентифицировался при взаимодействии с сайтом. Это означает, что мне нужен токен refre sh. Однако токен refre sh должен быть действителен только, например, для последнего взаимодействия с пользователем + xx минут. Я не могу расширять токен доступа при каждом запросе, так как нет никакого способа занести в черный список токены доступа. Это будет означать, что протекший токен доступа похож на мастер-ключ навсегда (если вы постоянно нажимаете на API через 15-минутные интервалы). Но я также не знаю, каким может быть срок действия маркера запроса.

Вторая проблема - (2) с режимами инкогнито или несколькими устройствами. Предполагая, что пользователь открывает 20 личных вкладок и использует запомнить меня на всех из них. Затем я должен хранить 20 токенов в базе данных. Я мог бы, конечно, установить ограничение для типа "web", чтобы сказать 5 и "app", равным 3, и удалить самый старый последний доступный из базы данных (и, следовательно, сделать его недействительным). Но это приведет его к выходу из «основного» браузера, если он откроет 5 личных вкладок. Это также ограничило бы количество телефонов, например, до 2.

Различные ПК / ноутбуки также генерировали бы много refre sh токенов типа web. Как лучше всего определить соответствующее устройство, чтобы доступ можно было отозвать, но я также не храню сотни токенов refre sh в течение всего времени жизни приложения? Лучше всего будет один refre sh токен на устройство (windows + firefox, iPhoneA, iPhoneB, windows2 + firefox). Но определить настольные P C очень сложно.

То, что сводится к следующему:

1. Как я могу хранить токены refre sh в БД, чтобы они были идентифицируемый для конечного пользователя (например, веб-сайты Whatsapp "Safari, запущенный в Нью-Йорке в последний раз в xxx-xxx-xxx"
2. Как избежать использования сотен токенов на пользователя в БД (см. ссылку sh токен в основном никогда не истекает, и пользователь может открывать столько личных вкладок, сколько ему угодно, не выходя из системы.)
3. Как я могу реализовать скольжение windows с помощью шаблона токенов обновления / доступа? Так что без ограничений refre sh токен на стороне клиента, но также нет выхода из системы по истечении срока действия токена доступа. Я мог бы иметь его в хранилище сеанса, но затем он по-прежнему загромождает мою базу данных и показывает пользователю, что «в данный момент вошел в систему» "(который отображает все refre sh токены), поскольку он в основном все еще действителен.

Answer 1

Раздвижная сессия на сайте. Это означает, что если пользователь взаимодействовал с веб-сайтом в течение последних XX минут, он не должен выходить из системы

Чтобы решить эту проблему, вы можете использовать токен refre sh, т. Е. Когда пользователь входит в систему для в первый раз приложение вернет токен доступа (формат JWT) с датой истечения срока, установленной на желаемую сумму. Когда пользователь будет просматривать приложение, ваш бэкэнд вернет заголовок X-Refre sh -Token, действительный для вашего xx времени (т.е. вам нужно будет возвращать этот заголовок для каждого вызова бэкенда) .

Если срок действия токена истек (бэкэнд прочитает используемый токен доступа и выполнит проверку поля токена срока действия), бэкэнд вернет ошибку 401 Unauthorized, и ваш клиент должен вызвать конечную точку аутентификации , предоставляя последний сохраненный токен refre sh, чтобы выдать новый токен доступа.

С этой реализацией ваше требование # 1 выполнено.

Запомнить меня на сайте. Когда это проверено, пользователь не должен выходить из системы (или после очень долгого времени)

Чтобы решить эту проблему, вам просто нужно сгенерировать токен длительного доступа (т.е. с срок действия установлен на желаемое время).

Пользователь не должен выходить из приложения

Я не понимаю этого

Доступ может быть отменен пользователем (зарегистрированным в данный момент) или указанными c событиями (смена пароля).

Это действительно сложно. Поскольку бэкэнд не имеет состояния, отозвать токен доступа - это действительно сложная топика c. Надеемся, что существует множество шаблонов для решения этой проблемы, нам просто нужно обсудить это.