В идеале у вас должен быть обработчик в ваших вызовах API, который проверял бы, скоро ли истекает срок действия JWT, и предварительно выполнял бы дополнительный вызов к серверу, чтобы запросить замену токена. Если пользователь активно взаимодействует с вашим приложением, refre sh должен происходить тогда, когда это необходимо, а не чаще, уменьшая количество обращений к вашему приложению.
В одном из моих проектов у нас есть APIClient класс, содержащий методы для всех необходимых нам вызовов, например getOwnUser и getTicketById, каждый из которых вызывает метод, который фактически выполняет запрос, fetchJSON.
fetchJSON Метод проверяет действительность JWT, используя дату, хранящуюся в Cook ie, перед выполнением запроса. Если срок его действия близок к истечению или истек, метод выполнит еще один вызов, чтобы запросить новый токен, используя refreshToken, выданное во время выпуска исходного (или последующего замещающего) токена. Если срок действия старого токена еще не истек, оба этих вызова могут быть выполнены одновременно, поэтому для пользователя не будет задержек. использовал (!) если получилось. Чтобы исправить это, вы можете просто подождать, пока истечет срок действия JWT, прежде чем обновлять его, хотя это может вызвать кратковременную задержку для пользователя во время выполнения дополнительного вызова. Хотя это результат, которого вы пытаетесь избежать.
Пока вы избегаете хранения JWT и обновляете sh токен (если вы решите использовать его) в localstorage, все будет в порядке. Вы также должны убедиться, что срок действия вашего JWT достаточно короткий (мы используем 15 минут), поскольку их невозможно отозвать, не замедляя проверку на стороне сервера и не делая их использование бессмысленным.