Мой вопрос в основном связан с этим последним шагом. Так как эти refre sh токены все еще технически действительны, так как они имеют длительный срок действия. Могу ли я создать таблицу в моей базе данных с именем "blacklisted_tokens" или что-то в этом роде и сохранить там значения токена? И затем, прямо перед генерацией нового токена доступа, перед этой проверкой следует проверить, есть ли этот refre sh токен в этой базе данных или нет, то есть он будет в черном списке.
делать это не рекомендуется потому что вероятность генерации 2 одинаковых токенов мала, и добавление НЕ необходимых дополнительных процессов в ваш бэкэнд не является хорошей идеей и имеет проблемы с производительностью при крупномасштабной регенерации токенов (много пользователей ).
А также токены и идентификатор (id), в котором снижаются риски безопасности.
на вашем месте я просто переписал бы новый токен в старый токен .
Самым важным типом кибератак, угрожающих токенам, является Атака с использованием анализатора , и, выполнив следующие шаги, вероятность этой атаки практически сводится к нулю:
- SSL-сертификат
- Истекающий токен и повторная генерация
- Соленые запросы
Соль
В криптографии соль является случайной данные, которые используются в качестве дополнительного ввода в одностороннюю функцию, которая хэширует данные, пароль или фразу-пароль. Соли используются для защиты паролей в хранилище.