У меня возникла проблема, из-за которой я нигде не нахожу защищенный и обслуживаемый ответ.
Представьте, что панель инструментов выполняет несколько запросов одновременно, как вы обрабатываете refresh_tokens чистым и стандартным способом?
Стек (даже если стек здесь не имеет значения):
Backend - Laravel с токеном JWT внешний интерфейс аутентификации - Vue JS с топором ios для вызовов API
Конечные точки:
- / auth / login (publi c )
- / auth / refre sh -token (требуется авторизация)
- / statistics (требуется авторизация)
- / other-статистика (требуется авторизация)
- / event-more-statistics (требуется авторизация)
- / final-statistics (требуется авторизация) ...
JWT refre sh рабочий процесс
- Пользователь переходит на mywebsite.com / login на клиенте
- Страница входа выполняет API-вызов к серверу
axios.get('/auth/login').then(res => setTokenAndUser(res)) - Сервер отвечает access_token (li fetime 1 мин) и refresh_token (срок службы 1 месяц или около того)
- Пользователь переходит на mywebsite.com / dashboard
- Пользователь нажимает на что-то, Dashboard страница выполняет 4 вызова API параллельно с 4 последними конечными точками, указанными выше
// ... just some pseudo code
userDidAction() {
axios.get('/statistics').then(res => handleThis(res.data));
axios.get('/other-statistics').then(res => handleThat(res.data));
axios.get('/event-more-statistics').then(res => handleThisAgain(res.data));
axios.get('/final-statistics').then(res => handleThatAgain(res.data));
}
// ...
- Первый вызов завершается, сервер делает недействительными старые токены + отвечает новыми access_token & refresh_token
- 2-й вызов заблокирован сервером, потому что он переносит устаревший токен
- 3-й вызов заблокирован сервером, потому что он переносит устаревший токен
- 4-й вызов заблокирован сервером, потому что он переносит устаревший токен
- Клиент / пользовательский интерфейс не обновлен правильно
Это очень распространенный сценарий для приложений SPA и SaaS. Наличие нескольких асинхронных вызовов API не является крайним случаем.
Какие у меня есть варианты?
- не делает недействительными токены:
- , но затем возникает брешь в безопасности, и использование токенов JWT становится бесполезным
- отслеживание каждого сбоя вызовов API и их повторное воспроизведение при изменении токена refre sh
- трудно поддерживать и создает непредсказуемые варианты поведения в пользовательском интерфейсе для пользователя
- , если пользователь взаимодействует во время повторов вызова, он будет портить обработчики вызовов
- каждый вызов ax ios имеет обещание, чтобы ожидаем хорошей обработки, которую мы должны будем хранить и откладывать каждое обещание также для того, чтобы интерфейс обрабатывался правильно
- каждый новый повтор также будет заново создавать новые токены каждый раз
Моя текущая идея заключается в том, чтобы access_token последние 3 дня и refresh_token длились месяц со следующим рабочим процессом:
- Когда интерфейс s tarts, мы проверяем допустимость access_token на стороне клиента
- , если refresh_token истек, стираем токены с клиента
- , иначе ничего не делаем
- если срок действия access_token истекает более чем через 12 часов, отправьте все последующие запросы вместе с ним
- , в противном случае используйте токен refre sh для получения новых токенов
Это делает refresh_token меньшим перемещением в сети и делает невозможным параллельное сбой, поскольку мы меняем токены только при начальной загрузке внешнего интерфейса, и, следовательно, токены будут жить как минимум 12 часов, прежде чем произойдут сбои.
Несмотря на то, что это решение работает, я ищу более безопасный / стандартный способ, какие-нибудь подсказки?