Комментарии 2
Сейчас у вас если злоумышленник перехватил пару токенов, то он может оставаться в системе как угодно долго, поскольку рефреш-токен у вас никогда не меняется.
Логика работы должна быть более сложной.
При аутентификации пользователя генерируется пара токенов — короткоживущий основной (например, на 15 минут) и рефреш на длительный срок (например, сутки). Рефреш-токен записывается в отдельную таблицу с привязкой к пользователю. На каждое устройство/сеанс генерируется своя пара.
При запросе с просроченным основным токеном сервер возвращает требование обновления токена. Клиент в ответ присылает рефреш-токен.
Если такого рефреш-токена нет в таблице, то отправляем требование аутентификации через логин/пароль.
Если рефреш-токен есть в таблице, но помечен как использованный, значит где-то произошла утечка. В этом случае удаляем все рефреш-токены данного пользователя и на всех устройствах/во всех сеансах ему надо будет войти через логин/пароль.
Иначе отмечаем рефреш-токен как использованный.
Проверяем корректность рефреш-токена и срок его действия. Если рефреш-токен недействительный или просроченный, то отправляем требование аутентификации через логин/пароль.
Если с рефреш-токеном всё в порядке, то генерируем новую пару из основного и рефреш-токенов и отправляем клиенту. Не забываем записать рефреш-токен в таблицу.
Периодически чистим таблицу от сильно (например, больше недели) просроченных рефреш-токенов.
Логика работы должна быть более сложной.
При аутентификации пользователя генерируется пара токенов — короткоживущий основной (например, на 15 минут) и рефреш на длительный срок (например, сутки). Рефреш-токен записывается в отдельную таблицу с привязкой к пользователю. На каждое устройство/сеанс генерируется своя пара.
При запросе с просроченным основным токеном сервер возвращает требование обновления токена. Клиент в ответ присылает рефреш-токен.
Если такого рефреш-токена нет в таблице, то отправляем требование аутентификации через логин/пароль.
Если рефреш-токен есть в таблице, но помечен как использованный, значит где-то произошла утечка. В этом случае удаляем все рефреш-токены данного пользователя и на всех устройствах/во всех сеансах ему надо будет войти через логин/пароль.
Иначе отмечаем рефреш-токен как использованный.
Проверяем корректность рефреш-токена и срок его действия. Если рефреш-токен недействительный или просроченный, то отправляем требование аутентификации через логин/пароль.
Если с рефреш-токеном всё в порядке, то генерируем новую пару из основного и рефреш-токенов и отправляем клиенту. Не забываем записать рефреш-токен в таблицу.
Периодически чистим таблицу от сильно (например, больше недели) просроченных рефреш-токенов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Туториал: SvelteKit JWT авторизация