Токены истечения срока действия электронной почты без использования базы данных и удаления crontab

Question

У меня есть сервер API с аутентификацией (регистрация, логин, забытый пароль и т. Д. c ..) на основе сеанса токена JWT.

Когда пользователь забыл пароль, он получает электронное письмо с уникальным токеном и ссылку, по которой он может сбросить свой пароль.

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

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

Есть ли другой способ сделать это? Может быть, без использования базы данных?

Я думал о связывании UUID токена в строку JWT. Таким образом, мне не нужна строка базы данных. Но потом я понял, что этот токен будет действителен до истечения срока его действия, поэтому пользователь может бесконечно менять свой пароль. Единственное исправление, которое я вижу, - добавить этот токен в отозванный список (в базе данных) до истечения срока его действия, но затем я снова использовал базу данных: D

Есть идеи?

Answer 1

Я нашел ответ в этой статье :

Создать токен JWT, который зашифрован секретом, сделанным из password hash + time of last password change текущего пользователя. Таким образом, токен используется один раз, потому что после того, как пользователь меняет пароль, в следующий раз, когда кто-то попытается использовать этот токен снова, токен не будет правильно расшифрован (не зашифрован тем же секретом). Кроме того, если новый пароль совпадает со старым, токен по-прежнему не будет использоваться из-за дополнительной информации о временной отметке.

Другое решение, предлагаемое @Horatiu Jeflea, также заключается в использовании time of last password change пользователя для нашего преимущества. Просто игнорируйте запросы на изменение пароля, если токен был сгенерирован до последнего изменения. В этом решении (я лично думаю) маловероятно, что одновременно произойдут две смены пароля, что может испортить ситуацию, поэтому я воспользуюсь первым решением.

Answer 2

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

Тем не менее, вы можете отправить JWT токен в ссылке сброса пароля. Он будет иметь дату истечения срока действия и идентификатор пользователя. Пользователи не могут манипулировать подписанными токенами JWT, поэтому мы можем доверять им, когда они истекают. Таким образом, вам вообще не нужна запись в БД для отслеживания этого.