Что такое Refresh token в JWT?

Refresh Token в JWT: Объяснение и Практика

В системе аутентификации с использованием JWT (JSON Web Token), Refresh Token — это особый токен, используемый для безопасного получения новых Access Token'ов без необходимости повторной аутентификации пользователя (например, ввода логина и пароля). Это ключевой механизм для баланса между безопасностью и удобством пользовательского опыта.

Основная проблема и решение

Access Token — это короткоживущий токен (обычно срок жизни от 5 минут до нескольких часов), который клиент (например, браузер или мобильное приложение) отправляет с каждым запросом к API для подтверждения своих прав. Его короткий срок жизни минимизирует риск, если токен будет скомпрометирован (украден). Однако если Access Token истекает, пользователю приходится логиниться снова — это плохой UX.

Refresh Token решает эту проблему:

• Он имеет значительно больший срок жизни (дни, недели, месяцы).
• Он хранится более безопасно (не в браузере, а, например, в защищенном хранилище мобильного приложения или в HTTP-only cookie).
• Его единственная функция — запросить новый Access Token, когда текущий истекает. Он не используется для прямых запросов к API.

Типичный поток работы с JWT и Refresh Token

1. Первичная аутентификация: Пользователь вводит логин/пароль.
2. Сервер генерирует и отправляет пару: Сервер создает и отправляет клиенту два токена:

   {
       "access_token": "eyJhbGciOiJIUzI1NiIs...",
       "expires_in": 3600, // 1 час
       "refresh_token": "dGhpcyBpcyBhIHNlY3Jld...",
       "token_type": "Bearer"
   }
   

3. Клиент использует Access Token: Клиент включает access_token в заголовок Authorization: Bearer <токен> при каждом запросе к API.
4. Access Token истекает: Сервер возвращает ошибку 401 Unauthorized.
5. Обновление через Refresh Token: Клиент отправляет специальный запрос (например, на /api/refresh) с refresh_token в теле или заголовке.

   // Пример запроса на обновление на PHP-сервере
   $refreshToken = $request->input('refresh_token');
   // Проверяем токен в БД, его активность, не был ли он отозван
   if ($refreshTokenIsValid) {
       // Генерируем новый Access Token (с новым сроком)
       $newAccessToken = jwt_encode([
           'user_id' => $user->id,
           'exp' => time() + 3600
       ]);
       // Можно также выдать новый Refresh Token (ротация)
       $newRefreshToken = generate_refresh_token();
       // Сохраняем новый Refresh Token в БД, заменяя старый
       save_refresh_token($user->id, $newRefreshToken);
       // Отправляем новую пару клиенту
       return response()->json([
           'access_token' => $newAccessToken,
           'refresh_token' => $newRefreshToken
       ]);
   }
   

6. Продолжение работы: Клиент получает новый access_token и продолжает работать.

Ключевые принципы безопасности Refresh Token

• Одноразовое использование или ротация: После успешного использования Refresh Token для получения нового Access Token, исходный Refresh Token должен быть отозван или заменен на новый. Это предотвращает повторное использование, если токен был перехвачен.
• Проверка на сервере: Refresh Token должен быть проверен сервером. Часто он хранится в базе данных (refresh_tokens таблица) вместе с метаданными (ID пользователя, срок жизни, статус "активен/отозван"). Это позволяет администратору отозвать токены (при потере устройства).
• Строгое хранение на клиенте: Refresh Token никогда не должен быть доступен JavaScript в браузере (для веб-приложений). Его следует хранить в HTTP-only, Secure Cookie или в защищенном хранилище мобильного приложения (Keychain/Keystore).

Преимущества и Недостатки

Преимущества:

• Улучшенный UX: Пользователь остается "залогиненным" длительное время.
• Более безопасный оборот токенов: Кратковременные Access Token уменьшают риск.
• Контроль со стороны сервера: Возможность отозвать все Refresh Token'ы пользователя при необходимости.

Недостатки / сложности:

• Увеличенная сложность реализации: Необходимо управлять двумя типами токенов, их хранением и ротацией.
• Необходимость безопасного хранения на клиенте: Особенно критично для веб-приложений.
• Дополнительная нагрузка на сервер: Проверка Refresh Token'ов и их ротация требуют обращения к базе данных (в отличие от самодостаточных Access Token'ов JWT, которые можно проверять только криптографически).

В заключение, Refresh Token — это не часть стандарта JWT, но широко принятая практика, которая делает использование JWT для аутентификации более безопасным и удобным для пользователя. Он действует как "ключ для продления" короткоживущих сессий, реализуя принцип "краткосрочный доступ, долгосрочное разрешение".