Где хранится JWT токен?

Где хранить JWT токен: практики и рекомендации

JWT (JSON Web Token) — это стандартный механизм передачи данных между сторонами в компактном формате JSON. После того как сервер аутентифицирует пользователя и создает JWT, возникает ключевой вопрос: **где его хранить на клиентской стороне**? От этого выбора зависят безопасность, удобство и производительность приложения.

Основные подходы к хранению JWT

1. LocalStorage / SessionStorage

• LocalStorage: данные сохраняются до явного удаления через JavaScript или очистки браузера.
• SessionStorage: данные удаляются при закрытии вкладки браузера.
• Преимущества:

     - Простая реализация.
     - Доступ из любого JavaScript-кода на том же домене.
     - Большой объем хранилища (обычно ~5-10 МБ).

• Риски:

     - Уязвимость к XSS-атакам: злоумышленник может украсть токен, внедрив вредоносный скрипт.
     - Токен не защищен автоматически.

• Пример использования:

  // Сохранение токена после успешного входа
  localStorage.setItem('jwt_token', token);
  
  // Извлечение для отправки в заголовке запроса
  const token = localStorage.getItem('jwt_token');
  fetch('/api/data', {
      headers: {
          'Authorization': `Bearer ${token}`
      }
  });
  

2. HTTP-Only Cookies

• Cookie, доступный только серверу (не доступен через JavaScript).
• Преимущества:

     - Защита от XSS: скрипты не могут прочитать cookie.
     - Автоматическая отправка с каждым запросом на тот же домен (упрощает клиентский код).
     - Возможность установки флагов безопасности: `Secure` (только HTTPS), `SameSite`, `HttpOnly`.

• Риски:

     - Уязвимость к CSRF-атакам (но это решается с помощью `SameSite=Strict` и CSRF-токенов).
     - Ограниченный размер (~4 КБ).

• Пример установки на сервере (Go):

  http.SetCookie(w, &http.Cookie{
      Name:     "jwt_token",
      Value:    token,
      HttpOnly: true,
      Secure:   true,        // Только для HTTPS
      SameSite: http.SameSiteStrictMode,
      MaxAge:   3600,        // Срок жизни в секундах
  })
  

3. In-Memory (хранится в памяти JavaScript)

• Токен хранится в переменной JavaScript и уничтожается при закрытии вкладки.
• Преимущества:

     - Максимальная защита от XSS и кражи через расширения браузера.
     - Токен существует только во время сессии.

• Недостатки:

     - Потеря токена при обновлении страницы (требуется повторный логин).
     - Не подходит для долгоживущих сессий.

4. Связка Access Token + Refresh Token

• Access Token (короткоживущий, 15-30 минут): хранится в памяти или localStorage.
• Refresh Token (долгоживущий, дни/недели): хранится строго в HTTP-Only cookie или на сервере.
• Преимущества:

     - Снижение риска компрометации: даже если Access Token украден, он быстро истекает.
     - Плавное обновление сессии без повторного логина.

• Пример реализации:

  // После аутентификации
  func loginHandler(w http.ResponseWriter, r *http.Request) {
      accessToken := generateAccessToken(userID)
      refreshToken := generateRefreshToken(userID)
      
      // Сохраняем refresh token в HTTP-Only cookie
      http.SetCookie(w, &http.Cookie{
          Name:     "refresh_token",
          Value:    refreshToken,
          HttpOnly: true,
          Secure:   true,
      })
      
      // Возвращаем access token в теле ответа (клиент сохраняет в памяти)
      json.NewEncoder(w).Encode(map[string]string{
          "access_token": accessToken,
      })
  }
  

Рекомендации для Go-разработчика

1. Для веб-приложений (SPA/SSR):

   • Используйте связку Access + Refresh токенов.
   • Access Token передавайте в заголовке Authorization, клиент хранит его в памяти или localStorage (с учетом рисков XSS).
   • Refresh Token храните в HTTP-Only cookie с флагами Secure и SameSite=Strict.

2. Для мобильных приложений:

   • Храните токены в защищенных хранилищах (Keychain для iOS, Keystore для Android).
   • Используйте Refresh Token с обязательным привязкой к устройству.

3. Меры безопасности:

   • Всегда используйте HTTPS.
   • Реализуйте CSRF-защиту для endpoints, изменяющих состояние.
   • Ограничивайте срок жизни токенов (JWT-claim exp).
   • Реализуйте черный список (blocklist) токенов при логауте (если требуется немедленная инвалидация).
   • Подписывайте токены надежным алгоритмом (например, HS256 или RS256).

Заключение

Оптимальное место хранения JWT зависит от контекста приложения. Для большинства веб-приложений комбинация короткоживущего Access Token в памяти и долгоживущего Refresh Token в HTTP-Only cookie обеспечивает баланс безопасности и удобства. Go-разработчику важно реализовать эту логику на сервере, корректно устанавливая cookie и валидируя токены, а также предусмотреть механизмы инвалидации и обновления токенов.