Если вы реализуете ротацию токенов обновления, не лучше ли отслеживать текущий токен пользователя, чем заносить в черный список использованные?

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

Если вы вносите токены в черный список, вы очень быстро получите много токенов в черный список. Предположим, срок жизни вашего токена доступа составляет 5 минут, а время обновления — 7 дней. Если пользователь использует ваше приложение в течение часа, он внесет в черный список 12 токенов за это время. Если у вас большое количество пользователей, это будет много токенов в черном списке.

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

Почему бы просто не отслеживать текущий токен клиента? При каждом запросе на обновление вы просто проверяете, является ли предоставленный токен токеном текущего пользователя, если он не помещает значение токена в базу данных в «null». Вот почему пользователи будут вынуждены войти в систему, даже если они украли ваш токен обновления, поскольку текущий токен должен быть действительным даже для проверки базы данных, если он совпадает с текущим (поскольку, если токен обновления недействителен или истек, вы должны выйти из системы пользователя). В следующий раз, когда они войдут в систему, вы установите новый текущий токен обновления в базе данных, и вор ничего не сможет сделать с украденным токеном.

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

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

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

0 ответов

Другие вопросы по тегам