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

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

JWT (JSON Web Token) может храниться в различных местах в зависимости от типа приложения и требований безопасности. Рассмотрим основные варианты хранения.

1. localStorage (веб-браузер)

Это одна из самых распространённых практик для веб-приложений:

// Сохранение токена
localStorage.setItem("access_token", jwtToken);

// Получение токена
const token = localStorage.getItem("access_token");

Плюсы:

• Простота реализации
• Доступность из любого места приложения
• Сохранение при обновлении страницы

Минусы:

• Уязвимость к XSS (Cross-Site Scripting) — JavaScript может получить доступ
• Данные доступны для любого скрипта на странице

2. sessionStorage

Аналог localStorage, но с меньшим временем жизни:

sessionStorage.setItem("access_token", jwtToken);
const token = sessionStorage.getItem("access_token");

Особенности:

• Удаляется при закрытии вкладки
• Отделён от других вкладок

3. Cookies (рекомендуемый подход)

Большинство экспертов рекомендуют хранить JWT в httpOnly cookies:

# Backend (FastAPI пример)
from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.post("/login")
async def login(credentials: dict):
    token = generate_jwt_token(credentials)
    response = JSONResponse({"message": "Logged in"})
    response.set_cookie(
        key="access_token",
        value=token,
        httponly=True,  # Защита от JavaScript
        secure=True,    # Только HTTPS
        samesite="Lax", # Защита от CSRF
        max_age=3600    # Время жизни в секундах
    )
    return response

// Frontend — токен отправляется автоматически
fetch("/api/protected", {
    method: "GET",
    credentials: "include" // Важно: отправлять cookies
})

Плюсы:

• httpOnly флаг защищает от XSS — JavaScript не может прочитать
• Secure флаг — передача только по HTTPS
• SameSite — защита от CSRF атак
• Браузер автоматически отправляет в каждом запросе

Минусы:

• Сложнее с кросс-доменными запросами
• Требует настройки CORS

4. Memory (оперативная память)

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

let accessToken = null;

function setToken(token) {
    accessToken = token;
}

function getToken() {
    return accessToken;
}

Плюсы:

• Максимальная безопасность — недоступен XSS
• Быстрый доступ

Минусы:

• Теряется при обновлении страницы
• Требует рефреша токена при загрузке

5. Secure Storage (мобильные приложения)

Для React Native, Flutter и нативных приложений:

# Android Keystore / iOS Keychain
# Использование библиотек: react-native-secure-storage, flutter_secure_storage

Лучшие практики

Рекомендуемая архитектура:

┌─────────────────────────────────────┐
│       Веб-приложение (SPA)          │
├─────────────────────────────────────┤
│ Storage: httpOnly cookies           │
│ + Refresh token rotation            │
│ + CSRF protection                   │
└─────────────────────────────────────┘

1. Access Token (15-30 минут) → httpOnly cookie
2. Refresh Token (7-30 дней) → httpOnly cookie или secure storage
3. CSRF Token → обычный cookie или header

Пример с refresh токеном:

# Backend
from datetime import datetime, timedelta

def create_tokens(user_id: str):
    access_token = create_jwt(
        data={"sub": user_id},
        expires_delta=timedelta(minutes=15)
    )
    refresh_token = create_jwt(
        data={"sub": user_id, "type": "refresh"},
        expires_delta=timedelta(days=7)
    )
    return access_token, refresh_token

@app.post("/refresh")
async def refresh_access_token(request: Request):
    refresh_token = request.cookies.get("refresh_token")
    if not verify_refresh_token(refresh_token):
        raise HTTPException(status_code=401)
    
    new_access = create_jwt(data={"sub": user_id}, expires_delta=timedelta(minutes=15))
    response = JSONResponse({"status": "success"})
    response.set_cookie("access_token", new_access, httponly=True, secure=True)
    return response

Итоги

Вывод: Для web-приложений используй httpOnly cookies с флагами secure и samesite. Это золотой стандарт безопасности в 2026 году.