это хорошая идея, чтобы положить токены с истекшим сроком в черный список? - PullRequest
1 голос
/ 13 января 2020

Для начала вот как выглядит мой текущий поток аутентификации

  1. Пользователь входит в систему
  2. Пользователь получает назначенный и сохраненный в базе данных refresh_token (долгоживущий 7d)
  3. Клиент получает accestoken (недолговечный, 2 часа) и сохраняет его как повар ie. Клиент также получает зашифрованный ИД пользователя AES и сохраняет его как повар ie.
  4. Поскольку токен доступа не истек, пользователь продолжает использовать токен для навигации по сайту
  5. Срок действия маркера истекает
  6. Маркер доступа с истекшим сроком действия отправляется на конечную точку refre sh, поэтому и идентификатор пользователя (зашифрованный) в настоящее время хранится в наших файлах cookie.
  7. Сервер расшифровывает идентификатор пользователя и получает токен обновления, соответствующий пользователю, выбирая токен refre sh из базы данных, используя out userId.
  8. Теперь у нас на сервере есть наш токен обновления и accestoken, поэтому мы обновляем sh токен и отправляем обратно новый токен доступа. Мы также генерируем новый знак обновления и перезаписываем наш старый знак обновления в базу данных новым.

Мой вопрос в основном связан с этим последним шагом. Так как эти refre sh токены все еще технически действительны, так как они имеют длительный срок действия. Могу ли я создать таблицу в моей базе данных с именем "blacklisted_tokens" или что-то в этом роде и сохранить там значения токена? И затем, непосредственно перед созданием нового токена доступа, перед этой проверкой следует проверить, находится ли этот refre sh токен в этой базе данных, что означает, что он будет в черном списке.

Это диаграмма потока авторизации enter image description here

1 Ответ

1 голос
/ 21 января 2020

Мой вопрос в основном связан с этим последним шагом. Так как эти refre sh токены все еще технически действительны, так как они имеют длительный срок действия. Могу ли я создать таблицу в моей базе данных с именем "blacklisted_tokens" или что-то в этом роде и сохранить там значения токена? И затем, прямо перед генерацией нового токена доступа, перед этой проверкой следует проверить, есть ли этот refre sh токен в этой базе данных или нет, то есть он будет в черном списке.

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

А также токены и идентификатор (id), в котором снижаются риски безопасности.

на вашем месте я просто переписал бы новый токен в старый токен .

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

  • SSL-сертификат
  • Истекающий токен и повторная генерация
  • Соленые запросы

Соль

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

...