Лучшие практики для аннулирования JWT при смене паролей и выходе из системы в node.js?

Когда используется токен No Refresh:

1.При смене пароля: когда пользователь меняет свой пароль, обратите внимание на время смены пароля в базе данных пользователя, поэтому, когда время смены пароля превышает время создания токена, токен недействителен. Следовательно, оставшаяся сессия скоро выйдет из системы.

2.Когда пользователь выходит из системы: когда пользователь выходит из системы, сохраните токен в отдельной БД (скажем: InvalidTokenDB и удалите токен из БД, когда истечет срок действия токена). Следовательно, пользователь выходит из соответствующего устройства, его сеансы на другом устройстве остаются нетронутыми.

Следовательно, при аннулировании JWT я выполняю следующие шаги:

1. Проверьте, действителен ли токен.
2. Если он действителен, проверьте, присутствует ли он в invalidTokenDB (базе данных, где токены, вышедшие из системы, хранятся до истечения срока их действия).
3. Если его нет, проверьте время создания токена и время смены пароля в базе данных пользователя.
4. Если время смены пароля ‹ время создания токена, то токен действителен.

Отношение к описанному выше методу:

1. Для каждого запроса API мне нужно выполнить все вышеперечисленные шаги, которые могут повлиять на производительность.

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

<сильный>1. При смене пароля: когда пользователь меняет свой пароль, измените токен обновления пользователя. Следовательно, оставшаяся сессия скоро выйдет из системы.

<сильный>2. Когда пользователь выходит из системы: когда пользователь выходит из системы, сохраните токен в отдельной БД (скажем: InvalidTokenDB и удалите токен из БД по истечении срока действия токена). Следовательно, пользователь выходит из соответствующего устройства, его сеансы на другом устройстве остаются нетронутыми.

Следовательно, при аннулировании JWT я выполняю следующие шаги:

1. проверить, действителен ли токен или нет
2. Если он действителен, проверьте, присутствует ли токен в InvalidTokenDB.
3. Если он отсутствует, проверьте токен обновления с помощью токена обновления в userDB.
4. Если равно, то это действительный токен

Отношение к описанному выше методу:

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

Примечание. Хотя Ханц предложил способ защитить токен обновления в Использование токена обновления в аутентификации на основе токенов защищено? , я не мог понять, что он говорит. Любая помощь приветствуется.

Итак, если у кого-то есть хорошее предложение, ваши комментарии приветствуются.

ОБНОВЛЕНИЕ: я добавляю ответ, если вашему приложению не нужен токен обновления с истечением срока действия. Этот ответ был дан Sudhanshu (https://stackoverflow.com/users/4062630/sudhanshu-gaur). Спасибо Судханшу. Поэтому я считаю, что это лучший способ сделать это,

Когда не требуется токен обновления и не истек срок действия токена доступа:

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

Следовательно, при аннулировании JWT выполните следующие шаги:

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

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

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

Я не знаю способа произвольно аннулировать токен без участия базы данных так или иначе.

Будьте осторожны с подходом 2, если к вашему сервису можно получить доступ на нескольких устройствах. Рассмотрим следующий сценарий...

• Пользователь входит в систему с помощью iPad, токен 1 выдается и сохраняется.
• Пользователь авторизуется на сайте. Выпущен токен 2. Пользователь выходит из системы.
• Пользователь пытается использовать iPad, токен 1 был выпущен до того, как пользователь вышел из веб-сайта, токен 1 теперь считается недействительным.

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

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

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

Всякий раз, когда пользователь «активен», каждый раз выдавать новый токен аутентификации (действителен в течение 15 минут каждый раз). Если пользователь неактивен более 15 минут, а затем делает запрос (поэтому использует jwt с истекшим сроком действия), проверьте действительность токена обновления. Если он действителен (включая проверку базы данных), выдайте новый токен аутентификации.

Если пользователь «выходит из системы» либо на устройстве, либо через веб-сайт, уничтожьте оба токена обновления доступа на стороне клиента и, что важно, отмените действительность используемого токена обновления. Если пользователь меняет свой пароль на каком-либо устройстве, отмените все свои токены обновления, заставив их снова войти в систему, как только истечет срок действия их токена доступа. Это оставляет «окно неопределенности», но это неизбежно, если каждый раз не нажимать db.

Использование этого подхода также открывает для пользователей возможность «аннулировать» доступ к определенным устройствам, если это необходимо, как это наблюдается во многих крупных веб-приложениях.

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

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

Всякий раз, когда создается jwt, то есть во время входа в систему или изменения/сброса пароля, вставляйте jwt с идентификатором пользователя в таблицу и сохраняйте jti (в основном номер uuid) для каждого jwt. Тот же jti входит и в полезную нагрузку jwt. Фактически jti однозначно идентифицирует jwt. У пользователя может быть несколько jwts одновременно, когда доступ к учетной записи осуществляется с нескольких устройств или браузеров, и в этом случае jti различает устройство или пользовательский агент.

Таким образом, схема таблицы будет такой: jti | Логин пользователя. (и первичный ключ, конечно)

Для каждого API проверьте, есть ли jti в таблице, что означает, что jwt является допустимым.

Когда пользователь меняет или сбрасывает пароль, удалите все jti этого идентификатора пользователя из базы данных. Создайте и вставьте в таблицу новый jwt с новым jti. Это приведет к аннулированию всех сеансов со всех других устройств и браузеров, кроме того, который изменил или сбросил пароль.

Когда пользователь выходит из системы, удалите этот конкретный jti этого пользователя, но не все. Будет единый вход, но не один выход. Поэтому, когда пользователь выходит из системы, он не должен выходить из системы со всех устройств. Однако удаление всех jtis также приведет к выходу из системы со всех устройств.

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

Однако, чтобы свести к минимуму вмешательство в базу данных и возможные задержки, использование кеша, безусловно, поможет облегчить процесс обработки.

Примечание. Пожалуйста, объясните, если вы голосуете против.

Если пользователь меняет свой пароль, вы попадете туда. Но не хотите лезть в бд для авторизации?

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

Я согласен исключительно с ответом @gopinath, просто хочу добавить одну вещь: вы также должны удалить время смены пароля, когда срок действия всех ваших токенов истек, например, предположим, что вы установили 3-дневный срок действия для каждого токена, который истекает сейчас, вместо того, чтобы просто сохранять изменения время действия пароля в базе данных, вы также можете установить время истечения срока его действия 3 дня, потому что, очевидно, срок действия токенов до этого истечет, поэтому нет необходимости снова проверять каждый токен, чтобы узнать, превышает ли время его истечения время изменения пароля или нет