#jwt #basic-authentication #refresh-token
#jwt #базовая аутентификация #refresh-token
Вопрос:
Я использую токены обновления с токенами доступа для аутентификации. Существует небольшая вероятность того, что токены обновления могут конфликтовать друг с другом, и это вызывает проблему. Я знаю, что могу создать уникальную константу для токенов обновления в моей таблице, но это вызывает много операций для базы данных. Я направляюсь вторым путем в качестве гида, но я не уверен. А ты как думаешь ?
Комментарии:
1. Я думаю, вы подвергаете конфиденциальность своих пользователей высокому риску. Токен обновления должен быть уникальным и должен обладать криптографической случайностью. GUID не является. Вычислительные затраты на создание криптослучайных случайных значений минимальны и не вызывают никаких проблем с вашей базой данных.
2. Наличие криптографически случайных токенов обновления минимально, но разве их уникальность в базе данных не приводит к снижению производительности, когда в таблице токенов обновления много строк?
3. С криптослучайными случайными значениями и достаточным количеством битов у вас очень, очень маленький шанс получить дубликаты. Вы можете сделать математику самостоятельно: 2 ^ бит. Токены обновления будут отправляться от клиента относительно редко, поскольку токены доступа обычно имеют продолжительность истечения срока действия от 5 минут до нескольких часов. Обычно вы используете индекс в своей базе данных, и кэширование в памяти также не повредит. Я бы не стал внедрять такую систему самостоятельно, а использовал существующее решение с открытым исходным кодом.
4. В настоящее время я не использую уникальную константу столбца в своей базе данных, я создаю случайный токен обновления и использую этот токен для обновления токена доступа, как обычно. Вы правы в отношении возможностей сопоставлений, но даже небольшой шанс заставляет меня беспокоиться о безопасности, поэтому я не знаю, проверяю ли я базу данных на наличие сопоставлений перед созданием токена обновления или нет. Потому что это вызывает проблемы с производительностью. И я использую индекс для токена обновления, как вы указали. Жду ваших советов, спасибо.
5. Итак, вопрос в основном таков: должны ли мы проверять криптослучайные случайные значения из n бит на уникальность в БД при их создании. Есть плюсы и минусы. Я бы сделал это и использовал быстрый метод для его проверки. Итак, это сводится к вопросу, какое хранилище и индекс лучше всего подходят для этого в вашей базе данных, конечно, что-то в памяти, основанное на хэше. Если после профилирования окажется, что ваша база данных работает слишком медленно, здесь может помочь выделенное хранилище, такое как Redis или memcached.